<?xml version="1.0" encoding="UTF-8"?>
<issueReport xmlns="urn:com:vector:pes:issuereport"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="urn:com:vector:pes:issuereport Interchange_Format_IssueReport-v1.xsd">
   <schemaVersion>1</schemaVersion>
   <reportData>
      <title>Open Issues in 'CBD1700369'</title>
      <reportCreationDate>2018-01-30</reportCreationDate>
      <reportIdentifier>CBD1700369-D04-2018-01-30-11:00:00</reportIdentifier>
   </reportData>
   <license>
      <licenseNumber>CBD1700369</licenseNumber>
      <customer>Nexteer Automotive Corporation
Package: MSR BAC 4.x -  ECU product "Electric Power Steering"</customer>
      <vectorContactEmail>EmbeddedSupport@us.vector.com</vectorContactEmail>
      <maintenanceExpiryDate>2018-08-01</maintenanceExpiryDate>
   </license>
   <deliveries>
      <delivery>
         <releaseNumber>D04</releaseNumber>
         <slp>MSR BAC 4.x</slp>
         <sip>19.06.14</sip>
      </delivery>
   </deliveries>
   <issues>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097673</identifier>
         <package>Il_AsrIpduMCfg5</package>
         <subpackage>root</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Rx Container PDUs with invalid content are forwarded to PduR</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Defective Container PDUs with invalid layouts are forwarded to PduR via PduR_IpduMRxIndication().
The ECU continues to behave normally.

When does this happen:
-------------------------------------------------------------------
Always and immediately.

In which configuration does this happen:
-------------------------------------------------------------------
Any configuration where Postbuild Selectable is configured
AND
IpduMContainerRxPdu do not exist with the IpduMContainerRxHandleId == 0 and all IpduMContainerRxHandleIds in one Predefined Variant have Gaps in the numerical Range.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>6.01.00</firstAffectedVersion>
         <versionsFixed>8.00.02</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097848</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Dem_GetWIRStatus returns E_OK for unavailable events</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
API Dem_GetWIRStatus returns E_OK when called for an unavailable event. 


When does this happen:
-------------------------------------------------------------------
Always and immediately


In which configuration does this happen:
-------------------------------------------------------------------
(Dem/DemGeneral/DemUserControlledWirSupport == TRUE)
AND
(
(Dem/DemConfigSet/DemEventParameter/DemEventAvailableInVariant == FALSE for the concerned event)
OR
(Dem/DemGeneral/DemAvailabilitySupport == DEM_EVENT_AVAILABILITY and concerned event is set unavailable by API Dem_SetEventAvailable)
)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>6.02.00</firstAffectedVersion>
         <versionsFixed>12.01.04, 14.04.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00096806</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Wrong signal specific ComXf transformations in fan-out / postbuild scenario</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
In a fan-out scenario with signal specific transformation or in postbuild scenario with variant specific transformation
only a single ComXf transformer is used although the transformation properties differ.


When does this happen:
-------------------------------------------------------------------
This happens during runtime


In which configuration does this happen:
-------------------------------------------------------------------
ComXf is used in fan-out or postbuild scenario
Signal or variant specific transformation properties
The order of the signals within the pdu differs in the variants</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.08.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097849</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Dem_GetEventEnableCondition returns E_OK for unavailable events</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
API Dem_GetEventEnableCondition returns E_OK when called for an unavailable event. 


When does this happen:
-------------------------------------------------------------------
Always and immediately


In which configuration does this happen:
-------------------------------------------------------------------
(Dem/DemGeneral/DemEnableConditionSupport)
AND
(
(Dem/DemConfigSet/DemEventParameter/DemEventAvailableInVariant == FALSE for the concerned event)
OR
(Dem/DemGeneral/DemAvailabilitySupport == DEM_EVENT_AVAILABILITY and concerned event is set unavailable by API Dem_SetEventAvailable)
)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>6.02.00</firstAffectedVersion>
         <versionsFixed>14.04.00, 12.01.04</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097699</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Dem_SetWIRStatus is processed and returns E_OK for unavailable events</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
API Dem_SetWIRStatus is processed and returns E_OK when called for an unavailable event. 


When does this happen:
-------------------------------------------------------------------
Always and immediately


In which configuration does this happen:
-------------------------------------------------------------------
(Dem/DemGeneral/DemUserControlledWirSupport == TRUE)
AND
(
(Dem/DemConfigSet/DemEventParameter/DemEventAvailableInVariant == FALSE for the concerned event)
OR
(Dem/DemGeneral/DemAvailabilitySupport == DEM_EVENT_AVAILABILITY and concerned event is set unavailable by API Dem_SetEventAvailable)
)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>6.02.00</firstAffectedVersion>
         <versionsFixed>12.01.04, 14.04.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097850</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Dem_GetEventAvailable returns AvailableStatus 'True' for events unavailable in variant</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
API Dem_GetEventAvailable returns E_OK and AvailableStatus 'True' when called for an event unavailable in variant. 


When does this happen:
-------------------------------------------------------------------
Always and immediately


In which configuration does this happen:
-------------------------------------------------------------------
Dem/DemGeneral/DemAvailabilitySupport == DEM_EVENT_AVAILABILITY
AND
Dem/DemConfigSet/DemEventParameter/DemEventAvailableInVariant == FALSE for the event the API Dem_SetEventAvailable is called for.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>10.00.00</firstAffectedVersion>
         <versionsFixed>14.04.00, 12.01.04</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097662</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Configured ClearDTC finished notification does not occur</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The configured ClearDTC finished notification does not occur.

When does this happen:
-------------------------------------------------------------------
When a ClearDTC operation has finished.

In which configuration does this happen:
-------------------------------------------------------------------
Dem ClearDTC notifications (/MICROSAR/Dem/DemGeneral/DemEventMemorySet/DemClearDTCNotification) are configured. 
AND
NO notifications with /MICROSAR/Dem/DemGeneral/DemEventMemorySet/DemClearDTCNotification/DemClearDtcNotificationTime = START are configured
AND 
One or more notifications with /MICROSAR/Dem/DemGeneral/DemEventMemorySet/DemClearDTCNotification/DemClearDtcNotificationTime = FINISH are configured</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>13.02.00</firstAffectedVersion>
         <versionsFixed>14.03.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00093702</identifier>
         <package>Ccl_Asr4ComMCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>PNC Wake-up Indication does not work as specified in AUTOSAR</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Expected behavior is that a specific PNC is woken up and corresponding I-PDU groups are switched on.
Symptoms depend on the value of ComM/ComMGeneral/ComMSynchronousWakeUp
- if it is on, all PNCs are woken up. All PNCs that are in state PNC_NO_COMMUNICATION switch to PNC_PREPARE_SLEEP state and corresponding I-PDU groups are switched on. 
- if it is off, no PNC is woken up and corresponding I-PDU groups are not switched on.


When does this happen:
-------------------------------------------------------------------
This happens at run-time when ComM_EcuM_PNCWakeUpIndication(PncId) is called and at least one PNC with id != PncId is in state PNC_NO_COMMUNICATION.


In which configuration does this happen:
-------------------------------------------------------------------
PNC Wake-up functionality is enabled:
#define COMM_WAKEUPENABLEDOFPNC STD_ON has been generated to ComM_Cfg.h

PNC Wake-up functionality is enabled if at least one PNC fulfills the following conditions:
- the PNC is referenced by an EcuM Wake-up Source (EcuM/EcuMConfiguration/EcuMCommonConfiguration/EcuMWakeupSource/EcuMComMPNCRef) and
- the PNC is mapped to at least one EthIf Switch Port Group (ComM/ComMConfigSet/ComMPnc/ComMPortGroupsPerPnc).

Note, the main purpose of this functionality is configuration of Ethernet Switch Ports (switchable per PNC).</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>8.00.00</firstAffectedVersion>
         <versionsFixed>9.00.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097748</identifier>
         <package>If_AsrIfFeeSmallSector</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Memory corruption of management information leads to dead lock of corresponding block</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Memory corruption (e.g. double bit error caused by reset) leads to not repairable NVM/FEE block.
Application tries to write a block and FEE always stops processing the job because FLS issues an error while accessing FEE's management information.
FEE block can no longer be accessed by read or write jobs.

When does this happen:
-------------------------------------------------------------------
A reset can lead to an error in the flash hardware (e.g. double bit error) which issues a FLS error during read accesses. If FEE's management information is somehow affected by a such an error, FEE will no longer be able to read or write this block.


In which configuration does this happen:
-------------------------------------------------------------------
Every configuration.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed>2.00.01, 1.00.03</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097173</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Missing variant-specific callbacks for N:1 FanIn with queued transformed signals</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Variants-specific callbacks are missing in a FanIn scenario with signal and variant-specific queued transformation.


When does this happen:
-------------------------------------------------------------------
This happens during runtime


In which configuration does this happen:
-------------------------------------------------------------------
- ComXf is used with fanin
- Postbuild is used
- Signal and variant-specific queued transformation</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.05.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097813</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Wrong transformer buffer size for fan in use case</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The buffer length check reduces the buffer length to a value that is smaller than the created transformation buffer.
Potentially, the returned data are invalid.

When does this happen:
-------------------------------------------------------------------
This happens during runtime.

In which configuration does this happen:
-------------------------------------------------------------------
This can happen in configurations with fan-in transformer use cases.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.12.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00098037</identifier>
         <package>Il_AsrIpduMCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Some contained Tx Pdus with last-is-best semantic not appearing on the bus</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
During transmission of a last-is-best container PDU, some contained PDUs are removed from the container before transmission. They are missing in the container.
The ECU continues to work normally.

When does this happen:
-------------------------------------------------------------------
Always for the affected contained PDUs, never for unaffected contained PDUs.

In which configuration does this happen:
-------------------------------------------------------------------
Configurations that match all of the following conditions:
- Contained last-is-best PDUs are configured
- At least one of the last-is-best PDUs has a header ID that is not unique in the IpduM module</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>6.06.00</firstAffectedVersion>
         <versionsFixed>6.07.01</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00094333</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Timeout Action Replace doesn't work for Rx SignalGroups with Array Access enabled</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The timeout Replace action for rx SignalGroups with array access enabled does not replace the buffer value either with the initial value or the configured  Rx Data Timeout Substitution Value.

When does this happen:
-------------------------------------------------------------------
During call of Com_MainFunctionRx()

In which configuration does this happen:
-------------------------------------------------------------------
In all configurations with rx SignalGroups which have a configured timeout &gt; 0, timeout action set to Replace and array access is enabled.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Disable Array Access for signalGroups if applicable (no use of com-based transformer)

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097951</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Wrong marshalling/ unmarshalling of &lt;XInt64&gt; Signals</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Signals/ GroupSignals with ComSignalType  &lt;XInt64&gt; are read / written incorrectly from/ to the bus.
A Rx Signal for example could be truncated when it's read by Com_ReceiveSignal.
    
When does this happen:
-------------------------------------------------------------------
Issue occurs at runtime

In which configuration does this happen:
-------------------------------------------------------------------
ComSignalType == UINT64 || SINT64
AND
ComBitPosition  starts at byte boundary
AND
32 Bits &lt; ComBitSize &lt; 64 Bits
AND
Signal does not end at byte boundary</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.



Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>11.00.00</firstAffectedVersion>
         <versionsFixed>12.00.03, 13.03.05, 14.01.02</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097324</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Missing TxAcknowledge in configurations with multiple variants</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Rte_Feedback reports RTE_E_NO_DATA or RTE_E_TIMEOUT although COM notified the transmission.


When does this happen:
-------------------------------------------------------------------
During runtime.


In which configuration does this happen:
-------------------------------------------------------------------
This happens when tx acknowledge is configured for a data element that is mapped to multiple signals (fan-out).
Moreover the project needs to use multiple postbuild variants.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.11.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithoutWorkaround">
         <identifier>ESCAN00097243</identifier>
         <package>Ccl_Asr4SmFr</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>FrSM debug data cannot be found in the map file</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
During A2L update several symbols of FrSM (that the FrSM generator actually registers through the CFG5 McData Service Interface) cannot be found in the map file.
FrSM_InternalState
FrSM_RequestedComMode
FrSM_StartupCounter
FrSM_Timer_ColdstartDelay
FrSM_Timer_RetryStartUp
FrSM_Timer_StartUpMonitoring
FrSM_WakeUpType



When does this happen:
-------------------------------------------------------------------
After compilation when  the A2L / calibration workflow is used to generate a complete A2L file with addresses of the target.

In which configuration does this happen:
-------------------------------------------------------------------
Whenever generation of Debug Data is enabled in DaVinci Configurator and FrSM is used.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.
 

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097707</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Unexpected DET during wakeup</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
DET DEM_E_WRONG_CONDITION is reported from Dem_Init.
Reason for the DET is that the SatelliteInit cannot be performed if the satellite is not in state PREINITIALIZED


When does this happen:
-------------------------------------------------------------------
During ECU wakeup


In which configuration does this happen:
-------------------------------------------------------------------
Configurations using a single partition for the Dem module
AND
DemGeneral/DemDevErrorDetect == true

Configurations using multiple partitions cannot use Dem_Init and need to use the specific API Dem_MasterInit / Dem_SatelliteInit.
In the latter case, the DET is expected, and is not reported due to the check for PREINITIALIZED</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The re-initialization of the satellite in Dem_Init is not necessary.

The issue can be circumvented in multiple ways:
	1) The DET report can be ignored (return from DET) - the satellite initialization is not performed in that case.
	2) Implement a different wakeup sequence: call Dem_MasterInit instead of Dem_Init


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>13.00.00</firstAffectedVersion>
         <versionsFixed>14.03.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00091305</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>EcuM with fixed state machine causes a Det error in Dem_Init because this module has been initialized two times</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
 In some situations the EcuM with fixed state machine calls Dem_Init() two times, this lead to a Det error thrown by the Dem with the message DEM_E_WRONG_CONDITION,


When does this happen:
-------------------------------------------------------------------
During runtime of the EcuM API EcuM_StartupTwo().


In which configuration does this happen:
-------------------------------------------------------------------
All of the following conditions have to be fulfilled to be affected by this issue:

- The Ecum with fixed state machine has to be active (EcuM/EcuMGeneral/EcuMEnableFixBehavior).
- The include Dem has to be active (EcuM/EcuMFixedGeneral/EcuMIncludeDem).
- At least one wakeup source has to be configured for wakeup validation (EcuM/EcuMConfiguration/EcuMCommonConfiguration/EcuMWakeupSource/EcuMValidationTimeout).
- At startup the standard wakeup source (ECUM_WKSOURCE_RESET) has to be cleared via the API EcuM_ClearWakeupEvent() to force a wakeup validation after startup and to prevent a transition to RUN state until this wakeup source is validated.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
In case that the valid wakeup event during initialization (ECUM_WKSOURCE_RESET) is cleared in context of driver init list two or three and a wakeup event for validation is set the Dem_Init call has to be avoided.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097019</identifier>
         <package>Security_AsrCsm</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>NON-RTE: Csm_MainFunction declaration is missing</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The declaration of the Csm_MainFunction is actually missing when the RTE is not part of the configuration.

When does this happen:
-------------------------------------------------------------------
This issue happens always and immediately

In which configuration does this happen:
-------------------------------------------------------------------
This issue happens with a non-RTE stack only</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Declare the Csm_MainFunction within a global header file:

FUNC(void, CSM_CODE) Csm_MainFunction(void);


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00095664</identifier>
         <package>Ccl_Asr4SmFr</package>
         <subpackage>Doc_TechRef</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Misleading description of the call sequence SetTransceiverMode and GetTransceiverWUReason at startup</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The Technical Reference describes that the wake up reason will be determined before the transition T01 is triggered.

But the Transceiver Mode is set to FRTRCV_TRCVMODE_NORMAL before the determination of the wakeup reason (FrIf_GetTransceiverWUReason) because the action does not depend at the result.
 

In which configuration does this happen:
-------------------------------------------------------------------
FrSMIsWakeupEcu == TRUE
FrSmCheckWakeupReason == TRUE
wake up by Trcv is possible</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Pay attention that the Transceiver Mode is set to FRTRCV_TRCVMODE_NORMAL before the determination of the wakeup reason (FrIf_GetTransceiverWUReason).

 

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097520</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Callout Dcm_FilterDidLookUpResult() is called with unexpected OpStatus</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The callout Dcm_FilterDidLookUpResult() is initially called with OpStatus DCM_PENDING instead of DCM_INITIAL.

When does this happen:
-------------------------------------------------------------------
When a specific DID within a DID range is requested over any DID related diagnostic service.
And the return value of the callout IsDidAvailable() is at least one time DCM_E_PENDING.
And the final return values of the very same callout are E_OK and DCM_DID_SUPPORTED.

In which configuration does this happen:
-------------------------------------------------------------------
- Any DID related diagnostic service is supported
AND
- DID ranges with gaps are supported (in Dcm_Cfg.h: #define DCM_DIDMGR_OPTYPE_RANGE_ISAVAIL_ENABLED == STD_ON)
AND
- External DID look up filtering is supported (in Dcm_Cfg.h: #define DCM_DIDMGR_EXTENDED_LOOKUP_ENABLED == STD_ON)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
- Just ignore the OpStatus within Dcm_FilterDidLookUpResult() if applicable (e.g. if filtering is done synchronously)
OR
- Manage the operation status by the application

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>5.00.00</firstAffectedVersion>
         <versionsFixed>9.01.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097860</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Doc_TechRef</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Service 0x2F. Sender/receiver missing ReturnControlToEcu specifics</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
In chapter "9.32  How to setup DCM for Sender-Receiver Communication" and more specifically "9.32.2  Application usage Scenario", there is missing an important hint to the ReturnControlToEcu" sequence that:
- In case the "inputOutputControlparameter" is equal to "ReturnControlToEcu" application shall not write any value to the "IOControlResponse" port. The reason is: the "ReturnControlToECU" operation is a synchronous "fire-and-forget" event, that does not need any confirmation resp. any confirmation will be ignored by DCM. 

The problem that might arise is that if the application writes 0x00 into this S/R port, while DCM already processes the new SID 0x2F request with operation other than the "ReturnControlToECU", DCM might interpret this delayed response signal as an acknowledgment to the new SID 0x2F request and accomplish the request with positive response. The bigger problem could arise if one of the "controlState" parameter in the "ShortTermAdjustment" request were invalid - DCM will update the "underControl" mask enabling the alternate values to be active. 


When does this happen:
-------------------------------------------------------------------
Implementing the S/R port for IOControlRequest for operation ReturnControlToECU.

In which configuration does this happen:
-------------------------------------------------------------------
- Service 0x2F is supported by DCM
AND
- There is any S/R IO-Control DID configured.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
During SW-C development that uses the IO-DID S/R ports, pelase consider following important information:
- The controlled IO-DID data elements shall use the overriden by SID 0x2F values only depending on the corresponding "underControl" data element. The application shall not copy this variable, but use it directly as a shared memory between DCM and the mapped IO-port.
- In case the "inputOutputControlOperation" has the value 0x00 (ReturnControlToEcu) it is not allowed the application to write any value into the IOControlResponse S/R port. In the described case, the application shall just do nothing, since the only operation done here is the reset of the "underControl" register, which is already done by DCM.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>8.06.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00098000</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Doc_TechRef</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Missing description of limitations to application data callbacks</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
At the moment the Dem only uses the Dem Master specific implementation of application data callbacks.
Due to this when using APIs Dem_GetEventFreezeFrameDataEx() or Dem_GetEventExtendedDataRecordEx() (which are provided on the Dem Satellites via the DiagnosticInfo port interface) a correct processing via the Rte can not be guaranteed in all situations/configurations.
The TechRef lacks the descriptions of the necessary restrictions (see Workaround).

When does this happen:
-------------------------------------------------------------------
Always and immediately

In which configuration does this happen:
-------------------------------------------------------------------
All</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Description of the missing restrictions is as follows:
When using APIs Dem_GetEventFreezeFrameDataEx() or Dem_GetEventExtendedDataRecordEx() the following restrictions hold to guarantee a correct callback processing via the Rte:
&gt;	Don’t map application data callback runnables to Os tasks.
&gt;	Provide application data callbacks on the same Os application as the Dem Master is located.
&gt;	If you use Sender/Receiver data callbacks, map the runnables Dem_GetEventFreezeFrameDataEx() and Dem_GetEventExtendedDataRecordEx() to the same Os task as Dem_MasterMainFunction.

Also only call APIs Dem_GetEventFreezeFrameDataEx() and Dem_GetEventExtendedDataRecordEx() from the master partition.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.00.00</firstAffectedVersion>
         <versionsFixed>8.04.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00096510</identifier>
         <package>FblTool_Hexeditor_Hexview</package>
         <subpackage>Application_Dll</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Signature generation produces incorrect output</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The generated signature is incorrect


When does this happen:
-------------------------------------------------------------------
During the signature generation of a file


In which configuration does this happen:
-------------------------------------------------------------------
When the input file (uncompressed file) exceeds a specific size (64MB)
AND
Data processing type 49 (ED25519PH on hashed Addr+Len+Data (SHA-512)) is used.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
1. Add the address and length information in front of the actual data (e.g. &lt;address&gt;&lt;length&gt;&lt;data&gt;). The address and length information are each 4 byte big. See manual chapter "2.2.3.5 Fill block data" or commandline interface "3.2.12 Fill region" and "3.2.13 Specify fill pattern".
2. Calculate the SHA-512 over the &lt;address&gt;&lt;length&gt;&lt;data&gt; using the type 19 (SHA-512 Hash Algorithm) . See manual chapter "2.2.3.6 Create checksum" or commandline interface "3.2.7 Checksum calculation method".
3. Calculate the ED25519 over the SHA-512 checksum using the type 46 (ECDSA (ED25519PH) on Data). See manual chapter "2.2.3.7 Run Data Processing" or commandline interface "3.2.8 Run Data Processing interface".


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.03.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00061207</identifier>
         <package>GenTool_ConfiguratorCfg5</package>
         <subpackage>Application</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>DaVinci Configurator 5: Issue Reporting Procedure</headline>
         <problemDescription>This ticket describes the reporting of DaVinci Configurator 5 issues. This ticket is a general information and not an issue.
-----------------------------------------------------------------------------------------------------------------------------------------

Issues of the DaVinci Configurator 5 tool are not part of the active issue reporting (i.e. this report).
The DaVinci Configurator 5 issue list can be downloaded from our home page:

DaVinci Developer OpenIssue Lists: https://portal.vector.com/web/davinci/shared-folder?t=c2b431ff-5dae-4a72-83ec-b9c8ca17561c
DaVinci Configurator OpenIssue Lists: https://portal.vector.com/web/davinci/shared-folder?t=15d156f3-65d3-4b6e-8107-ec44051aebff</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
This is not an issue but only a reference to the tool specific issue reporting.
No changes to the delivery required.</resolutionDescription>
         <firstAffectedVersion>5.00.01</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00096640</identifier>
         <package>Xf_E2eXf</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Initialization state may be cached</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
a) The E2EXf reports to DET that it is uninitialized and returns with a hard runtime error for some signals.
b) After E2EXf was deinitialized, it still performs as if initialized for some signals.

When does this happen:
-------------------------------------------------------------------

This can happen at the call of RTE_Read or RTE_Write for End-to-End protected signals in one OS application after E2EXF_Init (a) or E2EXF_DeInit (b) was called in another OS application.


In which configuration does this happen:
-------------------------------------------------------------------
The issue can occur in a configuration with two or more OS applications that has E2EXf protected signals in several of those OS applications.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
There are two possible workarounds:
1. The memory abstraction section START_SEC_VAR_ZERO_INIT_8BIT must be mapped to NOCACHE manually
2. In E2EXf_MemMap.h, change the target of the E2EXF_START_SEC_VAR_ZERO_INIT_8BIT to a NOCACHE section.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097884</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>DET check for pre-initialized satellite missing in Dem_SetEventStatus and Dem_ResetEventDebounceStatus</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
On call of APIs Dem_SetEventStatus (or the deprecated API Dem_ReportErrorStatus) and Dem_ResetEventDebounceStatus it is not verified that the respective satellite is pre-initialized, if the Development Error Detection is enabled.
Therefore the API calls will be accepted between Dem_MasterPreInit and the completion of Dem_SatellitePreInit, but reported data will be lost when Dem_SatellitePreInit is finished. 


When does this happen:
-------------------------------------------------------------------
Always on call of API Dem_SetEventStatus and Dem_ResetEventDebounceStatus  between Dem_MasterPreInit and the completion of Dem_SatellitePreInit (or the completion of Dem_PreInit which pre-initializes both master and satellite). 


In which configuration does this happen:
-------------------------------------------------------------------
Development Error Detection enabled</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Verify that APIs Dem_SetEventStatus (or the deprecated API Dem_ReportErrorStatus) and Dem_ResetEventDebounceStatus are not used before Dem pre-initialization (Dem_SatellitePreInit or Dem_PreInit) is finished.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>13.04.00</firstAffectedVersion>
         <versionsFixed>14.04.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097052</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Data send completed trigger fired to early when Rte_ComSendSignalProxyPeriodic is used</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A call to Rte_Write immediately triggers a runnable with data send completed trigger although COM did not call the confirmation callback, yet.

When does this happen:
-------------------------------------------------------------------
During runtime.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when a signal is sent from a different partition than the partition that contains the COM module and when transmission acknowlegement is configured.
Moreover a runnable needs to be configured to be triggered on data send completion.
It only happens when there are no additional internal receivers and when /MICROSAR/Rte/RteGeneration/RteEnforceIoc is enabled in the RTE configuration.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Configure an additional internal receiver.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.02.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097765</identifier>
         <package>Os_CoreGen7</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Wrong NOCACHE_ZERO_INIT sections in Os_MemMap.h</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The generated NOCACHE_ZERO_INIT sections in Os_MemMap.h are wrong.

For example:

#ifdef OS_START_SEC_GLOBALSHARED_VAR_NOCACHE_ZERO_INIT_BOOLEAN /* PRQA S 0883 */ /* MD_Os_0883 */
...
# undef MEMMAP_ERROR /* PRQA S 0841 */ /* MD_MSR_19.6 */
# pragma ghs section bss = ".OS_GLOBALSHARED_VAR_ZERO_INIT_bss"					&lt;= should be ".OS_GLOBALSHARED_VAR_NOCACHE_ZERO_INIT_bss"
# pragma ghs section data = ".OS_GLOBALSHARED_VAR_NOCACHE_ZERO_INIT"
# pragma ghs section sbss = ".OS_GLOBALSHARED_VAR_FAST_ZERO_INIT_bss"			&lt;= should be ".OS_GLOBALSHARED_VAR_FAST_NOCACHE_ZERO_INIT_bss"
# pragma ghs section sdata = ".OS_GLOBALSHARED_VAR_FAST_NOCACHE_ZERO_INIT"
# undef OS_START_SEC_GLOBALSHARED_VAR_NOCACHE_ZERO_INIT_BOOLEAN /* PRQA S 0841 */ /* MD_MSR_19.6 */
#endif


When does this happen:
-------------------------------------------------------------------
Always and immediately


In which configuration does this happen:
-------------------------------------------------------------------
Any configuration</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The linker-file can be patched manually.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.07.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00098036</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Cyclic PDUs with a ComGwRoutingTimeout are triggered when started if ComTxDlMonTimeBase is configured</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Periodic or Mixed Tx ComIPdu's with a configured ComGwRoutingTimeout might get triggered after their respective ComIPduGroup is started.

When does this happen:
-------------------------------------------------------------------
This issue occurs at runtime after the ComIPduGroup is started within the next Com_MainFunctionTx call.

In which configuration does this happen:
-------------------------------------------------------------------
Tx ComIPdu is part of any routing relation
AND
ComGwRoutingTimeout is configured for the Tx ComIPdu
AND
ComMainfunctionTimingDomainSupport is enabled
AND
ComTxDlMonTimeBase is configured</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Deactivate ComTxDlMonTimeBase

OR

Set resolution of ComTxDlMonTimeBase higher than ComTxCycleCounterTimeBase, such that ComTxCycleCounterTimeBase is a multiple of ComTxDlMonTimeBase.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>8.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00096248</identifier>
         <package>Gw_AsrPduRCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Validator PDUR12501 is not shown as error for PduRDestPduRef</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Validator message PDUR12501 is shown on a PduRDestPduRef. It is shown as information only, but in reality shall be an error message.


When does this happen:
-------------------------------------------------------------------
During live validation in the DaVinci Configurator 5.


In which configuration does this happen:
-------------------------------------------------------------------
The validator message is shown if the global Pdu of PduRDestPduRef is referenced by more than one other container. This kind of 1:N routing path is not supported.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Check if the validation message is shown for a PduRDestPduRef. 
If No, then you're not affected.
If Yes, check if this is correctly configured. The PduR will only forward the Pdu to one of the destination container (the destination is chosen randomly while generating due to the internal Java structure). The routing to this destination container will then work as configured.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>9.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097378</identifier>
         <package>Tp_Iso10681</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>FrTp issues DET error in case of erroneous termination of a high level routing (PduR does not provide tx-data it assured, before)</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
In case this issue occurs the FrTp issues a DET error in the context of FrTp_TriggerTransmit() of a segmented transmission with source data coming from a different &lt;Bus&gt;Tp ("high level routing", e.g. CanTp)
After the issue occurred the FrTp correctly ends the routing (the routing cannot continue because the &lt;Bus&gt;Tp has stopped receiving data)

The consequence, the implication is that the behavior is as expected: After the receiving TP has stopped receiving due to an error, the transmitting TP stops transmission, also.
Only the additional DET is unwanted.
    
The issue causes the unwanted / unexpected DET once but after that ECU continues to work and works correctly.


When does this happen:
-------------------------------------------------------------------
This happens only under specific circumstances namely in case:
- The receiving &lt;Bus&gt;Tp has successfully started receiving a segmented block of Pdus and encounters an error with one of the Pdus of this block that leads to the premature stop of the reception, e.g. a Sequence Number Error.
- And: Refer to "In which configuration does this happen:".


In which configuration does this happen:
-------------------------------------------------------------------
/ActiveEcuC/FrTp/FrTpGeneral[FrTpDevErrorDetect] is TRUE ( FRTP_DEV_ERROR_DETECT is STD_ON )
AND
The /ActiveEcuC/Dem module is active and configured.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The DET can be ignored. Thus there is no further workaround required.
Workaround could be to disable DET for FrTp.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.04.04</firstAffectedVersion>
         <versionsFixed>2.04.05</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097381</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Doc_TechRef</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Service 0x27: PowerOn delay time not started on single false access attempt</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The ECU allows at power-on/reset immediate security access attempt. In other words: the first security access request for getting a new seed is positively responded, instead of sending NRC 0x37 (DelayTimeNotExpired).

When does this happen:
-------------------------------------------------------------------
If the following sequence is ran:
- Security access request for getting seed of level X is positively responded.
- Security access request sending a key of level X failed with NRC 0x35 (i.e. prior reaching the false access attempt count limit).
- ECU is reset/powered down.
- ECU is online/powered on, already entered in a session supporting SID 0x27 and false access attempt delay time is not yet elapsed.
- Security access request for getting seed of level X is positively responded. &lt;--- According to ISO14229-1:2013 NRC 0x37 is expected here.

In which configuration does this happen:
-------------------------------------------------------------------
- Service 0x27 (SecurityAccess) is supported and implemented by DCM
AND
- The brute-force-attack prevention via access attempt count and delay time is enabled (in Dcm_Cfg.h #define DCM_STATE_SEC_RETRY_ENABLED == STD_ON)
AND
- The OEM does not override the defined in ISO14229-1:2013 defined behavior (i.e. the OEM may specify that the delay time at power-on/reset is started only if the restored attempt counter values is equal or greater than the specified limit other than single attempt)
AND
- The attempt counter(s) are stored into non-volatile memory (in Dcm_Cfg.h #define DCM_STATE_SEC_ATT_CNTR_EXT_STORAGE_ENABLED == STD_ON)
AND
	- The false access attempt count limit is &gt; 1 (in DCM ECUC there is at least one parameter: /Dcm/DcmConfigSet/DcmDsp/DcmDspSecurity/DcmDspSecurityRow/DcmDspSecurityNumAttDelay  &gt; 1)
	AND
	- The above affected level supports the non-volatile storage of its attempt counter (in DCM ECUC the corresponding parameter of container DcmDspSecurityRow: DcmDspSecurityAttemptCounterEnabled = TRUE)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The DCM application of the affected project shall implement the Xxx_SetSecurityAttemptCounter() API as follows:
- If DCM passed a value = 0, just store it into NvM
- If DCM passes a value &gt; 0, and the last stored in NvM values is 0, then and only then store the value 255. 
	Note: Value 255 is chosen to be configuration independent, in case the attempt count changes for instance from two to three.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed>9.03.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097264</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Description</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Service 0x2C: Valid DDDID definition requests always responded with NRC 0x31</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A diagnostic request for service 0x2C (DynamicallyDefineDataIdentifier) for definition of a DDDID (DynamicallyDefinedDID) is responded unexpectedly with NRC 0x31. 

After the issue occurred, the ECU is not blocked. All other services of the Dcm can be used normally.

When does this happen:
-------------------------------------------------------------------
Every time the affected by the configuration DDDID is requested for definition with service 0x2C.


In which configuration does this happen:
-------------------------------------------------------------------
- DCM supports and implements diagnostic service 0x2C (DynamicallyDefineDataIdentifier)
AND
- The affected DDDID is configured with 256 SourceItems (ECUC parameter /Dcm/DcmConfigSet/DcmDsp/DcmDspDidInfo/DcmDspDidAccess/DcmDspDidDefine/DcmDspDDDidMaxElements = 256)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Define only DDDID (DynamicallyDefinedDID) with "DcmDspDDDidMaxElements" up to 255 as restricted per AR DCM SWS 4.x.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.02.00</firstAffectedVersion>
         <versionsFixed>9.01.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097361</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Service 0x2A: Wrong prioritisation between NRC 0x13 and 0x31</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
ECU response with NRC 0x31 instead of NRC 0x13.


When does this happen:
-------------------------------------------------------------------
If a service 0x2A is requested with an unsupported transmissionMode and no periodicDataIdentifier.


In which configuration does this happen:
-------------------------------------------------------------------
- Service 0x2A is supported (in Dcm_Cfg.h: DCM_SVC_2A_SUPPORT_ENABLED == STD_ON)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Use supplierIndication function notification to catch this length check. 

Note: Since the supplier specific Xxx_Indication() calls is performed after the SID level checks are executed, no session, security or other verification shall be performed within this callout - only the length check.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.01.00</firstAffectedVersion>
         <versionsFixed>9.04.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00091550</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Service 0x27: Dcm allows seed/key attempt earlier than the configured security delay time</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A security delay timer expires too early. Dcm accepts new seed requests before the configured delay time is expired.


When does this happen:
-------------------------------------------------------------------
If after last unsuccessful attempt responded with Nrc 0x36 (exceededNumberOfAttempts) a new seed request is sent before the expected delay time.


In which configuration does this happen:
-------------------------------------------------------------------
- Service 0x27 is supported
AND
- There is more than one security level configured
AND
- Any delay time is configured for any security level (in Dcm_Cfg.h: DCM_STATE_SEC_RETRY_ENABLED == STD_ON or DCM_STATE_SEC_DELAY_ON_BOOT_ENABLED == STD_ON)
AND
- The dividend of a configured security delay time (in milliseconds) and the task cycle (also in milliseconds) is greater that 65535</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The equation shall become true: (&lt;TimeParameter&gt; / DcmTaskTime) &lt; 63535.

Therefore, the following workarounds are possible:
1) Increase the DcmTaskTime parameter value.
OR
2) Reduce the timeout value in the corresponding timing parameter.



Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097659</identifier>
         <package>Il_AsrIpduMCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Contained PDUs with sendTimeout = 0 not transmitted</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A continuously transmitted PDU (for example every 100ms) is sometimes seen on the bus only after 200, 300 or more ms.
A Queue Overflow DET occurs.

The ECU continues to behave normally.


When does this happen:
-------------------------------------------------------------------
On transmission of a contained PDU.


In which configuration does this happen:
-------------------------------------------------------------------
Configurations with Contained PDUs with ContainedPduSendTimeout = 0.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
EITHER:
Configure the sendTimeout to 1.
OR:
Delete the sendTimeout parameter and configure the contained PDU to "trigger always".

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>5.01.00</firstAffectedVersion>
         <versionsFixed>6.06.05</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097045</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Dem_SetEventAvailable returns E_OK for events unavailable in variant</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
API Dem_SetEventAvailable returns E_OK when called for an event unavailable in variant, although availability of this event cannot be changed during runtime. 


When does this happen:
-------------------------------------------------------------------
Always and immediately


In which configuration does this happen:
-------------------------------------------------------------------
Dem/DemGeneral/DemAvailabilitySupport == DEM_EVENT_AVAILABILITY
AND
Dem/DemConfigSet/DemEventParameter/DemEventAvailableInVariant == FALSE for the event the API Dem_SetEventAvailable is called for.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Don't call API Dem_SetEventAvailable for an event unavailable in variant.
At least don't assume that an event unavailable in variant is set available during runtime although API returns E_OK. 

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.00.00</firstAffectedVersion>
         <versionsFixed>12.01.04, 14.01.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097306</identifier>
         <package>Il_AsrSecOC</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Freshness Value Manager function is called within exclusive area</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The Os error “E_OS_DISABLEDINT” occurs when the SecOC requests a Freshness Value from the FvM

When does this happen:
-------------------------------------------------------------------
when SecOC requests a Freshness Value from the FvM.


In which configuration does this happen:
-------------------------------------------------------------------
IF Query Freshness Value == RTE</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Suspend only the BUS ISRs inside the EXCLUSIVE_AREA_RXSTATE.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed>6.00.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00096901</identifier>
         <package>If_AsrIfFeeSmallSector</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Possible incorrect interpretation of last page status</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Depending on the content, a block might not be readable although it has been written correctly before.
FEE may interpret content incorrectly, in case FlsBlankCheck is disabled for a block's partition.


When does this happen:
-------------------------------------------------------------------
If the last flash page of an instance is entirely filled with FlsEraseValue. FEE reads the last page of an instance to determine whether an erase abort has occurred. If the content of the last flash page of an instance matches the FlsEraseValue, FEE will interpret the last page as erased and consequently assumes an erase abort.


In which configuration does this happen:
-------------------------------------------------------------------
This is issue is only relevant if parameter Fee/FeePartitionConfiguration/FeeFlsBlankCheckApi is set to FALSE.
This issue is _NOT_ relevant for FEE usage on RH850 platform, because RH850 requires parameter Fee/FeePartitionConfiguration/FeeFlsBlankCheckApi to be set to TRUE.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
On RH850 platform it is highly recommended to enable parameter Fee/FeePartitionConfiguration/FeeFlsBlankCheckApi. With this parameter enabled, this issue does not apply.
If SmallSectorFee is used on a different platform, where no FlsBlankCheck is necessary, the last page of an instance should not match the FlsEraseValue. The user has to make sure that the last page of block is _NOT_ filled with the erase value.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.02</firstAffectedVersion>
         <versionsFixed>2.00.01</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097802</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Activation reason data type uses bit access</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
In the struct Rte_ActivatingEvent_&lt;ComponentTypeName&gt;_Type in Rte.c, an activating event for a runnable specifies a bit field length. This leads to a Misra Warning "The behavior of bit fields not of type int is undefined". 

When does this happen:
-------------------------------------------------------------------
Always and immediately

In which configuration does this happen:
-------------------------------------------------------------------
It happens when all of the following conditions are fulfilled:
- a runnable has an activation reason  AND
- the runnable is not triggered  by "On Operation Called", "On Mode Entry", "On Mode Exit" or "On Transition" AND
- RTE's optimization mode equals MEMORY</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Set Rte's optimization mode to RUNTIME.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.09.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00096508</identifier>
         <package>FblTool_Hexeditor_Hexview</package>
         <subpackage>Application_Dll</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compression produces wrong output</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The compressed output file contains invalid data


When does this happen:
-------------------------------------------------------------------
During the compression of a file


In which configuration does this happen:
-------------------------------------------------------------------
When the input file (uncompressed file) exceeds a specific size (64MB)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Split the file in smaller chunks (files) and compress them separately. After compressing merge the files together.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.03.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097474</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Incorrect calculation of 'Cycles Tested Since Last Failed' and 'Healing Counter Inverted'</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The Dem returns incorrect values for the internal data elements 'Cycles Tested Since Last Failed' and 'Healing Counter Inverted'.

When does this happen:
-------------------------------------------------------------------
Always when requesting the internal data elements 'Cycles Tested Since Last Failed' and 'Healing Counter Inverted' via extended data or snapshot records (by DCM service 19x04 or 19x06 or application APIs).


In which configuration does this happen:
-------------------------------------------------------------------
(All events have no indicator (Dem/DemConfigSet/DemEventParameter/DemEventClass/DemIndicatorAttribute) configured OR an indicator with Dem/DemConfigSet/DemEventParameter/DemEventClass/DemIndicatorAttribute/DemIndicatorHealingCycleCounterThreshold &lt;= 1)
AND
(Using data elements DEM_CYCLES_TESTED_SINCE_LAST_FAILED or DEM_HEALINGCTR_DOWNCNT (Dem/DemGeneral/DemDataClass/DemDataElementInternalData) in an extended data record (Dem/DemGeneral/DemExtendedDataRecordClass) or Did (Dem/DemGeneral/DemDidClass) )
AND
(Any DTC has Extended Data Records (Dem/DemConfigSet/DemEventParameter/DemExtendedDataClassRef) or Snapshot Records (Dem/DemConfigSet/DemEventParameter/DemFreezeFrameClassRef) configured)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Create an internal dummy event referencing an indicator and Dem/DemConfigSet/DemEventParameter/DemEventClass/DemIndicatorAttribute/DemIndicatorHealingCycleCounterThreshold.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>13.04.00</firstAffectedVersion>
         <versionsFixed>14.02.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00089164</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>The EcuM stays in RUN state even if EcuM_KillAllRunRequests has been called</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The ECU stays in RUN state, even if anyone has called the API EcuM_KillAllRunRequests.


When does this happen:
-------------------------------------------------------------------
Always after EcuM_KillAllRunRequests() has been called and at least one channel is in a state unequal COMM_NO_COM_NO_PENDING_REQUEST.


In which configuration does this happen:
-------------------------------------------------------------------
Only in configurations with ECUM_FIXED_BEHAVIOR is active (EcuM/EcuMGeneral/EcuMEnableFixBehavior).</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The following shows a possible workaround to ignore all ComM channel states in case of an active KillAllRUNRequests.

Hint: EcuM_SetWakeupEvent considers wakeup events even if EcuM_KillAllRUNRequests() was called. This might cause that the EcuM transits from PostRun to Run again, because of a new occurred wakeup event. 

The call of the API ComM_GetState() has to be mapped to an application function in case that it is called in context of EcuM.c. This can be done by configure the following header file as a User Configuration file in the EcuM configuration (EcuM/EcuMGeneral/EcuMUserConfigurationFile):

- Example Appl_ComM_EcuM.h:

#if defined (ECUM_SOURCE)
extern Std_ReturnType Appl_ComM_GetState(const NetworkHandleType Channel, ComM_StateType* State);

# define ComM_GetState Appl_ComM_GetState
#endif

- Example Appl_ComM_EcuM.c:

#include "Std_Types.h"
#include "ComM.h"

#define ECUM_PRIVATE_CFG_INCLUDE
#include "EcuM_PrivateCfg.h"
#undef ECUM_PRIVATE_CFG_INCLUDE


Std_ReturnType Appl_ComM_GetState(const NetworkHandleType Channel, ComM_StateType* State)
{
  Std_ReturnType retVal = E_OK;
  /* Verify that EcuM_KillAllRUNRequests() was not called */
  if ((EcuM_GetKillAllInProgress() &amp; (0x01u)) == 0u)
  {
    retVal = ComM_GetState(Channel, State);
  }
  else
  {
    /* In case of an active KillAllRunRequest, set the virtual ComM State to no communication and no request. */
    *State = COMM_NO_COM_NO_PENDING_REQUEST;
  }

  return retVal;
}


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097081</identifier>
         <package>If_AsrIfFr</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>DET error FRIF_E_INVALID_PDU_OWNER is thrown for Tx PDUs owned by CDD</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A DET error FRIF_E_INVALID_PDU_OWNER might be thrown for Tx PDUs owned by a Complex Device Driver "CDD".

When does this happen:
-------------------------------------------------------------------
This happens in context of TxConfirmation for the transmitted PDU.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when the FrIf PDU has all of the following properties:
- Tx PDU
- PDU Owner is CDD (parameter FrIfUserTxUL set to CDD)
- A TriggerTransmit function is configured (parameter FrIfUserTriggerTransmitName set to a non-empty value)
- No TxConfirmation function is configured (parameter FrIfTxConfirmationName is empty)
- Tx confirmations are enabled for the PDU (parameter FrIfConfirm is true)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
- Make sure a Tx confirmation function (parameter FrIfTxConfirmationName) is provided, if Tx confirmations are enabled (parameter FrIfConfirm) for a PDU with CDD as upper layer.
- If no Tx confirmation function is provided (parameter FrIfTxConfirmationName), manually disable Tx confirmations for the PDU (parameter FrIfConfirm).

Resolution:
-------------------------------------------------------------------
Not yet available.</resolutionDescription>
         <firstAffectedVersion>4.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00092116</identifier>
         <package>FblDrvFlash_Rh850Rv40His</package>
         <subpackage>Impl_Base</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Long runtime of flash library functions can delay the Rx frame processing</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Flash library operations might be very runtime consuming.
This might delay the processing of a Rx frame that long, that the corresponding CAN mailbox has already been overwritten with the following Rx frame assigned to the mailbox.
The download will abort with a NRC 0x73 (WrongBlockSequenceCounter).


When does this happen:
-------------------------------------------------------------------
During the flash routines of the flash library.


In which configuration does this happen:
-------------------------------------------------------------------
-Usage of pipelined programming/early acknowledge
-So far the behavior has only been detected on F1H and F1K derivatives</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Driving the system with a higher clock also speed up the flash operations and reduces their runtime.
(verified with R7F7015032+R7F7015874AFP @ 120MHz)

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.06.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097583</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Rte_Feedback does not return RTE_E_UNCONNECTED when a signal is not connected in all variants</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Rte_Feedback does not return RTE_E_UNCONNECTED.


When does this happen:
-------------------------------------------------------------------
During runtime.


In which configuration does this happen:
-------------------------------------------------------------------
This happens when the configuration uses transmission acknowledgement for a port that does not contain
a data mapping for all variants.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Check the variant before calling the Rte_Feedback API.
Please note that the RTE does not provide a specific API for the variant check.
A possible solution could be to check the return value of an Rte_Read API that is unconnected in the same
variant or to set the variant through a CDD.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.05.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00096716</identifier>
         <package>Rte_Analyzer</package>
         <subpackage>Application</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Queued sender/receiver N:1 connections not detected</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RteAnalyzer reports that configuration contains more queued connections and/or more APIs with queues.


When does this happen:
-------------------------------------------------------------------
The error is issued during analysis of the code  by RteAnalyzer in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This happens for configurations with queued sender/receiver N:1 communication over partition boundaries, when all senders are mapped to the same OsApplication.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Ensure that the reported connections exist in the code. Afterwards, the message can be disregarded,

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>0.09.00</firstAffectedVersion>
         <versionsFixed>1.01.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097729</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Add support for software component instance specific transformer handling</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A RTE API returns an unexpected transformer error.


When does this happen:
-------------------------------------------------------------------
During runtime.


In which configuration does this happen:
-------------------------------------------------------------------
This happens when the configuration contains multiple instantiated software components and when both instances are connected
to a signal that is protected with E2EXf.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Use two different component types instead of instantiating the same component type multiple times.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.10.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097731</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Service 0x10: Jump to FBL performed although forced RCR-RP could not be sent</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
For a HIS compatible jump to FBL DCM triggers always a reset, independently of whether the forced RCR-RP could be sent by the transmission layer or not.


When does this happen:
-------------------------------------------------------------------
Whenever a jump to FBL is requested, e.g. via a 0x10 0x02 request.


In which configuration does this happen:
-------------------------------------------------------------------
- Service 0x10 is supported (in Dcm_Cfg.h: #define DCM_SVC_10_SUPPORT_ENABLED == STD_ON)
AND
- Jump to bootloader is supported (in Dcm_Cfg.h: #define DCM_SVC_10_JMP2BOOT_ENABLED == STD_ON)
AND
- RCR-RP on jumping to the FBL is supported (in Dcm_Cfg.h: #define DCM_DIAG_RCRRP_ON_BOOT_ENABLED == STD_ON)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The workaround for this issue involves overriding default service handling for service "DiagnosticSessionControl" (0x10).

Please contact Vector for technical details and support on how to implement it in order to avoid any unwanted side effects.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.02.00</firstAffectedVersion>
         <versionsFixed>9.03.00</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097141</identifier>
         <package>Cp_Asr4Xcp</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>The Xcp Module ID is not according to AR 4</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The service Xcp_GetVersionInfo() currently reports a MODULE_ID = 26. This value was used during the AR3 phase but is not according to AR4. In AR4 the MODULE_ID shall be 212.


When does this happen:
-------------------------------------------------------------------
Always and immediately


In which configuration does this happen:
-------------------------------------------------------------------
All configurations.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The version information returned by Xcp_GetVersionInfo() can be interpreted accordingly (with different MODULE_ID)


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed>1.00.01</versionsFixed>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00097982</identifier>
         <package>DrvTrans_Tja1082FrdiospiAsr</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>TXEN related error flags are not reliably detected in polling mode</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
In Simple Error Indication Mode the error flags are not latched. That means that they are only visible as long as they persist.
The visibility duration of some errors is very short especially those that are related to the TXEN pin (Bus error, TXEN clamped). The duration is to short to reliably detect them in polling mode.

As a result such errors may go unnoticed and no DEM error is thrown.


When does this happen:
-------------------------------------------------------------------
Always and immediately.


In which configuration does this happen:
-------------------------------------------------------------------
When bus error detection is used</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Use a user.cfg file:

/* User Config File Start */

#if defined (FRTRCV_30_TJA1082_SOURCE)
extern Dio_LevelType ApplDio_ReadChannel(Dio_ChannelType DioChannel);
#define Dio_ReadChannel ApplDio_ReadChannel
#endif

/* User Config File End */

and provide the following function (pseudo code):

Dio_LevelType ApplDio_ReadChannel(Dio_ChannelType DioChannel)
{
  Dio_LevelType level;
  
  level = Dio_ReadChannel(DioChannel);
  if(DioChannel == DioConf_DioChannel_DioChannel_ERRN)
  {
    if(INTERRUPT_FLAG_ERRN == TRUE)
    {
       level = STD_LOW;
    }
    CLEAR_INTERRRUPT_FLAG_ERRN;
  }
  
  return level;
}


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00096309</identifier>
         <package>Ccl_Asr4SmFr</package>
         <subpackage>Implementation</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>&lt;Cdd&gt;_SyncLossErrorIndication is not called as defined within the ASR SWS</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
FrSM is calling the &lt;Cdd&gt;_SyncLossErrorIndication without the &lt;SyncLossErrorStatus&gt; parameter.
FrSM is not calling the &lt;Cdd&gt;_SyncLossErrorIndication in all scenarios defined by the ASR SWS. 


When does this happen:
-------------------------------------------------------------------
In case of a sync loss the &lt;Cdd&gt;_SyncLossErrorInidcation is called by the FrSM but without the &lt;SyncLossErrorStatus&gt;.
In case that the synchronization is reestablished the &lt;Cdd&gt;_SyncLossErrorInidcation is not called at all in contrast to what ASR is defining.


In which configuration does this happen:
-------------------------------------------------------------------
This happens when a &lt;Cdd&gt;_SyncLossErrorInidcation function is defined within the FrSM</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The DEM event DemEventClusterSyncLoss is called at the same moments.
So the Dem callout can be used instead.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="runtimeIssueWithWorkaround">
         <identifier>ESCAN00096249</identifier>
         <package>Gw_AsrPduRCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Medium</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Validator PDUR12501 is not shown as error for PduRSrcPduRef for not supported source modules</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Validator message PDUR12501 is shown on a PduRSrcPduRef. It is shown as information only, but in reality shall be an error message for source modules which do not support N:1 fan in on global Pdu level.


When does this happen:
-------------------------------------------------------------------
During live validation in the DaVinci Configurator 5.


In which configuration does this happen:
-------------------------------------------------------------------
The validator message is shown if the global Pdu of PduRSrcPduRef is referenced by more than one other container. This kind of N:1 routing path is only supported for communication interface Pdus of SoAd, CanIf and FrIf.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Check if the validation message is shown for a PduRSrcPduRef. 
If No, then you're not affected.
If Yes, this kind of configuration is only supported for communication interface Pdus of the SoAd, CanIf and FrIf module. Everything else shall not be configured.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>9.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00093171</identifier>
         <package>Cp_XcpOnFrAsr</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>MainFunctions still declared for AR4</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The FrXcp_MainFunctionRx/Tx are declared in the AR4 use case. As a result a MISRA warning will occur.


When does this happen:
-------------------------------------------------------------------
Always and immediately


In which configuration does this happen:
-------------------------------------------------------------------
all configurations</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The MISRA warning has no functional impact and can be ignored.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00098167</identifier>
         <package>Rte_Asr4</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>RTE01081 Model object &lt;/MICROSAR/IoHwAb_swc/ComponentTypes/IoHwAb&gt; of command line parameter -m is invalid.</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE SWC Template generation in CFG5 aborts with an error message
RTE01081	Model object &lt;/MICROSAR/IoHwAb_swc/ComponentTypes/IoHwAb&gt; of command line parameter -m is invalid.


When does this happen:
-------------------------------------------------------------------
During SWC template generation.

In which configuration does this happen:
-------------------------------------------------------------------
This happens in configuration that contain the IoHwAb component.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.00.00</firstAffectedVersion>
         <versionsFixed>4.18.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096635</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Missing variable name in case of multiple receivers when ComXf is used</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compilation of the RTE fails because in Rte.c an Rte_COMCbk function passes a buffer &amp;[0] to Com_ReceiveSignalGroupArray.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when ComXf is configured for a signal group that is received from different software components in different partitions.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Receive the signal only in one software components and forward the data within the component to the other components.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.08.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00098062</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>RTE49999: When InitializeImplicitBuffers is configured for implicit connections to NvBlock SWCs</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE Generator aborts with a RTE49999 error.


When does this happen:
-------------------------------------------------------------------
During generation.


In which configuration does this happen:
-------------------------------------------------------------------
This happens when all of the following conditions are true:
- /MICROSAR/Rte/RteGeneration/RteInitializeImplicitBuffers is configured to true
- the access to the data elements is implicit
- the configuration contains a sender-receiver connection to a NvBlock SWC and the NvBlock has no RAM block init value
  or
  the nv port is not connected</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Connect all Nv ports with implicit accesses.
Configure RAM block init values for the NvBlocks.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.09.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00095310</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: identifier EcuM_GlobalConfigRoot not declared</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The compiler throws the following (or similar) error:

"../../../external/BSW/EcuM/EcuM.c", line 2959: error (dcc:1525): identifier EcuM_GlobalConfigRoot not declared


When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.


In which configuration does this happen:
-------------------------------------------------------------------
Only in PB-S configurations with MCAL modules which do only support PB-L.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
1. Workaround:
This workaround does only work if in /ActiveEcuC/EcuC/EcucGeneral/BswInitialization no entry exists for one of those MCAL modules with entry "AdditionalInitCode" and without a ConfigPtrName set.

Add MCAL modules which do only support PB-L to the list of individual Postbuild modules in the configuration of the module EcuC:

EcuC/EcucGeneral/PostbuildLoadable/IndividualPostBuildLoadableModule


2. Workaround:
If Workaround 1 is not working because of the restrictions mentioned in the 1. workaround please use the following workaround:

Adaption of the files EcuM_Init_Cfg.h and EcuM_Init_Cfg.c. The adaption of these files is okay because these are template files.

Adapt the EcuM_Init_Cfg.h as follows:
...
extern CONST(EcuM_GlobalConfigRootType, ECUM_CONST) EcuM_GlobalConfigRoot; 
...


Adapt the EcuM_Init_Cfg.c as follows:
....
CONST(EcuM_GlobalConfigRootType, ECUM_CONST) EcuM_GlobalConfigRoot =
{
&lt;CONTENT&gt;
};
....



Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00088036</identifier>
         <package>If_AsrIfFr</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: PduR_FrIfTxConfirmation is not defined</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A compilation error occurs because the symbol PduR_FrIfTxConfirmation is not defined.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
Configuration having all of the following characteristics:
1. PduR/PduRBswModules/PduRTxConfirmation is set to FALSE.
2. A PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/PduRDestPdu where the parameter PduR/PduRRoutingTables/PduRRoutingTable/PduRRoutingPath/PduRDestPdu/PduRTransmissionConfirmation is not instantiated.
3. A FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfTxPdu where the parameter FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfTxPdu/FrIfConfirm is set to TRUE and the FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfTxPdu/FrIfUserTxUL is set to PDUR.
4. The PduRDestPdu and the FrIfTxPdu have a reference to the same EcucDefs/EcuC/EcucPduCollection/Pdu.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Manually set the parameter FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfTxPdu/FrIfConfirm to FALSE in all the FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfTxPdu that have the parameter FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfTxPdu/FrIfUserTxUL set to PDUR

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097476</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>RTE01004 error during contract phase generation (Could not read back DVCfgRteGen data)</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE generation is incorrectly aborted with RTE01004 'Could not read back DVCfgRteGen data' error message.


When does this happen:
-------------------------------------------------------------------
During contract phase header generation.


In which configuration does this happen:
-------------------------------------------------------------------
This happens for all configuration when 'Contract phase header' is selected as 'Generation Mode' inside Cfg5 project settings.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Change Cfg5 project settings so that 'Template file and contract phase header' is selected as 'Generation Mode'.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.12.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00073545</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Final FBL response not cancelled on protocol preemption</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The ECU will process the FBL final response even if there is higher protocol request sent.

When does this happen:
-------------------------------------------------------------------
When immediately after reprogramming of the ECU has ended, the very first request after ECU powers on in the application is a hi-priority one (i.e. OBD).

In which configuration does this happen:
-------------------------------------------------------------------
- Any configuration where the ECU shall be able to send a final response without request after reset.
AND
- Protocol prioritisation is to be supported (i.e. OBD vs. UDS).</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.05.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097053</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Empty struct DCM_DIDMGROPTYPEREADCONTEXTTYPE_TAG</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
During Dcm.c compilation with VC compiler following error occurs:
error C2016: C requires that a struct or union has at least one member

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
- Service 0x22 (ReadDataByIdentifier) is active and handled by DCM
AND
- DCM is configured to support DIDs with multiple signals (in Dcm_Cfg.h: #define DCM_DIDMGR_MULTISIGNAL_ENABLED == STD_ON)
AND
- None of the multi signal DIDs support read operation (in Dcm_Cfg.h: #define DCM_DIDMGR_MSIG_OPTYPE_READ_ENABLED == STD_OFF)
AND 
- None of single signal DIDs does support paged read access (in Dcm_Cfg.h: #define DCM_DIDMGR_OPCLS_READ_PAGED_ENABLED == STD_OFF)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Split a DID with a read access having a single signal into two data signals.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00086584</identifier>
         <package>SysService_E2ePw</package>
         <subpackage>Generator</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>E2E Generation fails silently</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
E2EPW source code is not generated by execution of the E2EPW generator from DaVinci Configurator Pro, although no error message is reported.


When does this happen:
-------------------------------------------------------------------
This error occurs for wrong user configurations, in some cases if the E2E generator is not capable of producing source code for a configuration, but the E2E preprocessor is not able to detect the issue.


In which configuration does this happen:
-------------------------------------------------------------------
This occurs in configurations where the data length of a E2E protected signal group is set incorrectly in the ECU extract of system description (possibly by manual configuration in DaVinci Developer).</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
If no E2EPW source code is generated, please
- navigate to the tab "Generation Result" in DaVinci Configurator
- right click on E2EPW, select "Show Generation Console Output"
- an error message will be displayed that explains the error based on the intermediate E2E configuration file. Please find the description of this file in the E2EPW User Manual.

Resolution:
-------------------------------------------------------------------
n.a.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097274</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Incompatible Rte_MemCpy prototypes</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compilation fails because the prototype for Rte_MemCpy or Rte_MemCpy32 is incompatible to the prototype in the RTE implementation.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when the platform does not define uint16_least and uint32_least to the same types and when the configuration contains a component with
sender-receiver communication or inter-runnable variables with arrays.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Typedef uint16_least and uint32_least to the same type.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.13.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097477</identifier>
         <package>Ccl_Asr4ComMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Code generation is not possible due to error RTE13068 - Insufficient data type to represent mode value</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
DaVinci Configurator reports the following error
[Error] RTE13068 - Insufficient data type to represent mode value 
- The Mode Transition Value of Mode Declaration Group &lt;ComMMode&gt; is set to &lt;3&gt;.
This value can not be represented by &lt;ComM_ModeType&gt; data type.

When does this happen:
-------------------------------------------------------------------
The error is issued by the RTE generator during calculation phase.

In which configuration does this happen:
-------------------------------------------------------------------
This issue is reported as a preventive measure. We assume that the issue does not occur.
It was detected in a DaVinci Configurator Service Pack, which is not distributed anymore.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.00.00</firstAffectedVersion>
         <versionsFixed>9.00.01</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00094298</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>The Ecu does not startup properly in some MultiCore configurations</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The Ecu does not startup properly, e.g. communication does not start , the application is not started, the configuration variant is not detected correct etc.


When does this happen:
-------------------------------------------------------------------
Always after startup of the Ecu.


In which configuration does this happen:
-------------------------------------------------------------------
In MultiCore configurations with parameter "/EcuM/EcuMGeneral/EcuMBswCoreId" set to another value than to the ID of the master core

AND 

The OS symbols OS_CORE_ID_&lt;X&gt; are provided as a enumeration and not as a preprocessor define.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Create a header file with the following content and add it to /MICROSAR/EcuM/EcuMGeneral/EcuMUserConfigurationFile:

#if defined(ECUM_CFG_H)

# undef ECUM_CORE_ID_STARTUP
# undef ECUM_CORE_ID_BSW
# define ECUM_CORE_ID_STARTUP                                     &lt;Core Id as Numerical Value, e.g. '0&gt;
# define ECUM_CORE_ID_BSW                                              &lt;Core Id as Numerical Value, e.g. '1&gt;

#endif



Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00087948</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Update Bits are not cleared if Com_IpduGroupControl is called with initialize = false</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
After a IpduGroup is stared with initialize = false a Signal is transmitted with set Update Bit although signal was not updated since the IpduGroup was stopped.

When does this happen:
-------------------------------------------------------------------
during the call of Com_IpduGroupControl or Com_IpduGroupStart.

In which configuration does this happen:
-------------------------------------------------------------------
If Tx UpdateBits are used
AND
if Com_IpduGroupControl/ Com_IpduGroupStart is used with initialize = false</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097056</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: 'Offset' : is not a member of 'DCM_DIDMGROPTYPEREADCONTEXTTYPE_TAG'</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
During Dcm.c compilation with VC compiler following error occurs:
error C2039: 'Offset' : is not a member of 'DCM_DIDMGROPTYPEREADCONTEXTTYPE_TAG'

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
- Service 0x22 (ReadDataByIdentifier) is active and handled by DCM
AND
- DCM is configured to support DIDs with multiple signals (in Dcm_Cfg.h: #define DCM_DIDMGR_MULTISIGNAL_ENABLED == STD_ON)
AND
- None of the multi signal DIDs support read operation (in Dcm_Cfg.h: #define DCM_DIDMGR_MSIG_OPTYPE_READ_ENABLED == STD_OFF)
AND 
- At least one of DIDs does support paged read access (in Dcm_Cfg.h: #define DCM_DIDMGR_OPCLS_READ_PAGED_ENABLED == STD_ON)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Split a DID with a read access having a single signal into two data signals.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00095259</identifier>
         <package>If_Asr4IfWd</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: WdgIf uses undefined memory sections</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
WdgIf uses memory section which are not defined. The WdgIf assumes erroneously that Os provides these sections. This error leads to a compiler error like: #error "MemMap.h, wrong pragma command"
The sections of the WdgIf 
- WDGIF_START_SEC_VAR_INIT_8BIT / WDGIF_STOP_SEC_VAR_INIT_8BIT
- WDGIF_START_SEC_VAR_INIT_16BIT / WDGIF_STOP_SEC_VAR_INIT_16BIT
- WDGIF_START_SEC_VAR_INIT_32BIT / WDGIF_STOP_SEC_VAR_INIT_32BIT
are mapped to
(Gen6)
- &lt;ApplicationName&gt;_START_SEC_VAR_&lt;InitPolicy&gt;_8BIT   / &lt;ApplicationName&gt;_STOP_SEC_VAR_&lt;InitPolicy&gt;_8BIT
- &lt;ApplicationName&gt;_START_SEC_VAR_&lt;InitPolicy&gt;_16BIT / &lt;ApplicationName&gt;_STOP_SEC_VAR_&lt;InitPolicy&gt;_16BIT
- &lt;ApplicationName&gt;_START_SEC_VAR_&lt;InitPolicy&gt;_32BIT / &lt;ApplicationName&gt;_STOP_SEC_VAR_&lt;InitPolicy&gt;_32BIT.
(Gen7)
- OS_START_SEC_&lt;ApplicationName&gt;_VAR_&lt;InitPolicy&gt;_8BIT   / OS_STOP_SEC_&lt;ApplicationName&gt;_VAR_&lt;InitPolicy&gt;_8BIT
- OS_START_SEC_&lt;ApplicationName&gt;_VAR_&lt;InitPolicy&gt;_16BIT / OS_STOP_SEC_&lt;ApplicationName&gt;_VAR_&lt;InitPolicy&gt;_16BIT
- OS_START_SEC_&lt;ApplicationName&gt;_VAR_&lt;InitPolicy&gt;_32BIT / OS_STOP_SEC_&lt;ApplicationName&gt;_VAR_&lt;InitPolicy&gt;_32BIT.

Os currently supports only "InitPolicy" {-, NOINIT, ZEROINIT}. The actually needed init policy is "INIT".


When does this happen:
-------------------------------------------------------------------
Only if a multi core plattform is used and the WdgIf is configured to use the state combiner functionality.


In which configuration does this happen:
-------------------------------------------------------------------
If a container "/MICROSAR/WdgIf/WdgIfStateCombiner" is configured
AND
if /MICROSAR/WdgIf/WdgIfGeneral/WdgIfUseStateCombiner == true</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Provide the missing memory sections and locate them in a proper memory section.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00098104</identifier>
         <package>GenTool_IRAnalyzer</package>
         <subpackage>Application</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>RTE Analyzer reports false out of bound accesses</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE generator reports an out of bound access although all write accesses are within the bounds.

When does this happen:
-------------------------------------------------------------------
This happens during analysis of write accesses with multiple possible pointer targets.
This means write accesses to array elements or write accesses to e.g. function parameters
that get passed different values in different call sites.
This only happens when the write access does not write the entire object.
E.g. when an element in a structure is written.
This only happens when the write access is an assignment, not a memcpy or memset.

In which configuration does this happen:
-------------------------------------------------------------------
This happens in all configurations.
See description above for the code structure of the analyzed code that leads to the ESCAN.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>0.09.00</firstAffectedVersion>
         <versionsFixed>1.01.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097525</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>RTE49999 when transformers are not configured for all fan-out signals</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE generation aborts with an RTE49999 error.

When does this happen:
-------------------------------------------------------------------
During generation.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when a data element is mapped to multiple signals and
when not all the signals are configured to use transformers.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.04.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096465</identifier>
         <package>FblWrapperFlash_Rh850Rv40His</package>
         <subpackage>Impl_Base</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Wrong macro used to activate "ECC Safe Read" feature in static code.</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The static code uses (expects)  FLASH_ENABLE_MACHINE_CHECK_ECC_DETECTION macro instead of FBL_FLASH_ENABLE_ECC_SAFE_READ (which is generated by the configuration tool) to activate the code for the ECC Safe Read feature, so this feature won't be active.



When does this happen:
-------------------------------------------------------------------
At compile time, when the ECC Safe Read option was activated in the configuration tool.





In which configuration does this happen:
-------------------------------------------------------------------
FblHalECCSafeRead == True</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The following compatibility define has to be set in the user configuration file

#if defined( FBL_FLASH_ENABLE_ECC_SAFE_READ )
# define FLASH_ENABLE_MACHINE_CHECK_ECC_DETECTION
#else
# define FLASH_DISABLE_MACHINE_CHECK_ECC_DETECTION
#endif</resolutionDescription>
         <firstAffectedVersion>1.07.00</firstAffectedVersion>
         <versionsFixed>1.08.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097910</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Dcm_Swc.arxml: Missing values of Mode-Declarations in Mode-Declaration-Groups</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE validation issues the following message:
RTE13077 - ModeDeclarationGroup &lt;NameMDG&gt; with explicit order does not specify a value for mode &lt;NameMode&gt;.


When does this happen:
-------------------------------------------------------------------
At RTE generation time.


In which configuration does this happen:
-------------------------------------------------------------------
- At least one "/Dcm/DcmConfigSet/DcmProcessingConditions/DcmModeRule" exists;
AND
- This ModeRule has at least one DcmArgumentRef to a "/Dcm/DcmConfigSet/DcmProcessingConditions/DcmModeCondition";
AND
- This ModeCondition has configured DcmBswModeRef:
	- DcmContextModeDeclarationGroupPrototype is set to a DCM ModeDeclarationGroup prototype;
	AND
	- DcmTargetModeDeclaration is set to a valid ModeDeclaration;</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Use a DaVinci Cfg5 version smaller than 5.14.8.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.00.00</firstAffectedVersion>
         <versionsFixed>9.04.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00081436</identifier>
         <package>FblDrvFlash_Rh850Rv40His</package>
         <subpackage>Impl_Base</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Using FlashDriver_SetResetVector() might cause exception</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
When using FlashDriver_SetResetVector() an exception occurs.

When does this happen:
-------------------------------------------------------------------
When code called from wdTriggerFct (typically FblLookForWatchdog()) is not located in RAM.
This may apply e.g. to the Communication Wrapper task functions.

In which configuration does this happen:
-------------------------------------------------------------------
if FLASH_ENABLE_SET_RESETVECTOR_API is enabled.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
 Either manually handle memDrvDeviceActive in the updater or locate any code referenced by FblLookForWatchdog() in RAM


Resolution:
-------------------------------------------------------------------
None.</resolutionDescription>
         <firstAffectedVersion>1.02.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00098155</identifier>
         <package>SysService_Asr4WdM</package>
         <subpackage>Doc_TechRef</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Inconsistencies of Technical Reference regarding Dem usage</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The technical reference was updated. In an earlier version of the WdgM the Dem was not directly connected to the WdgM. A wrapper was needed to handle the Dem. Now the documentation was updated, because there was a description how to implement this wrapper on several passage.

This description confuses the customer and is fixed. 


When does this happen:
-------------------------------------------------------------------
Missing updated documentation after further development of the component.


In which configuration does this happen:
-------------------------------------------------------------------
Always</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.
This is only an inconsistency in user documentation and therefore a workaround is not applicable. A "textual" workaround is that a wrapper is no more needed for Dem usage.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.02.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097938</identifier>
         <package>Security_AsrCsm</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Custom Algorithm modes and families lead to validation errors.</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
If custom family or custom mode is selected, the validation of the primitive configuration leads to an error even if the underlying crypto driver supports this configuration.

When does this happen:
-------------------------------------------------------------------
Always

In which configuration does this happen:
-------------------------------------------------------------------
If custom family or custom mode is used in primitive configuration.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
To use a custom algorithm family:
1. Set GenerateAlgorithmFamily to CRYPTO_ALGOFAM_CUSTOM
2. Set "User Defined Value" for GenerateAlgorithmFamily
3. Set AlgorithmFamilyCustom to the custom name.

Same holds for algorithm mode.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00094541</identifier>
         <package>SysService_Asr4BswMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Auto-Configuration Communication Control: Rules without expressions are created and so validation errors are shown</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The validation tab shows the following message:

AR-ECUC02008	Invalid multiplicity (3 messages)
	AR-ECUC02008	Mandatory parameter BswMRuleExpressionRef is missing in CC_&lt;CHANNELNAME&gt;_&lt;PNCNAME_RX
		BswMRuleExpressionRef
		/ActiveEcuC/BswM/BswMConfig/BswMArbitration/CC_&lt;CHANNELNAME&gt;_&lt;PNCNAME&gt;
	AR-ECUC02008	Mandatory parameter BswMRuleExpressionRef is missing in CC_&lt;CHANNELNAME&gt;_&lt;PNCNAME_RX_DM
		BswMRuleExpressionRef
		/ActiveEcuC/BswM/BswMConfig/BswMArbitration/CC_&lt;CHANNELNAME&gt;_&lt;PNCNAME&gt;
	AR-ECUC02008	Mandatory parameter BswMRuleExpressionRef is missing in CC_&lt;CHANNELNAME&gt;_&lt;PNCNAME_TX
		BswMRuleExpressionRef
		/ActiveEcuC/BswM/BswMConfig/BswMArbitration/CC_&lt;CHANNELNAME&gt;_&lt;PNCNAME&gt;

When does this happen:
-------------------------------------------------------------------
Always after execution of the Communication Control assistant.


In which configuration does this happen:
-------------------------------------------------------------------
In configurations with PNCs where at least one PduGroup is mapped to different PNCs

AND 

Not all PNCs of a channel are configured (selected) in the Communication Control assistant.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Rules must be deleted manually from configuration.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>11.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00091723</identifier>
         <package>Il_AsrIpduMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Generator error IPDUM90005 is reported for PduR routing paths from non-Com upper layer to IpduM</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
During code generation, IPDUM90005 is reported, code generation is aborted.

When does this happen:
-------------------------------------------------------------------
During code generation.

In which configuration does this happen:
-------------------------------------------------------------------
Any configuration where the IpduM is involved in a Tx routing path with an upper layer that is not the Com module.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
A configuration where the IpduM is involved in a Tx routing path with an upper layer that is not the Com module is not supported.
Update your system description and model the upper layer as Com.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096815</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: undeclared identifier Rte_CalprmRom_</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compilation fails because the compiler reports the usage of an undeclared identifier starting with Rte_CalprmRom_ in an OS application specific Rte_InitMemory.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when the configuration uses multicore or memory protection and when online calibration method single pointered is used.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Extend MemMap.h so that it provides the extern declaration when the RTE is compiled.

#if defined(RTE_CORE) &amp;&amp; defined(Rte_CalprmElementGroup_&lt;name&gt;)
extern CONST(&lt;name&gt;_Type, RTE_CONST_DEFAULT_RTE_CALPRM_GROUP) Rte_CalprmRom_&lt;name&gt;;
#endif


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.16.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097971</identifier>
         <package>Rte_Asr4</package>
         <subpackage>Generator</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>RTE49999: Mismatching constant values</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE generation aborts with an error message
RTE49999 Mismatching constant values: &lt;cfull&gt; and &lt;celement&gt;
although the elements use the same value.

When does this happen:
-------------------------------------------------------------------
During generation.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when the configuration contains sender-receiver communication where a sender only receives a subset of the record elements of the sender.
The problem occurs when the receiving component does not have a port access to the receiver port.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Configure port accesses for the receivers.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.07.00</firstAffectedVersion>
         <versionsFixed>4.18.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00094259</identifier>
         <package>SysService_Asr4BswMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Auto-Configuration Communication Control shows an error in case of not available module Com</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Auto-Configuration shows the following error:

Configuration *error*

Reason for *error*:
Could not collect all necessary informations. Solve errors in depending Modules first!

To see following errors in the Validation view execute on-demand generator validation!

Container ComConfig does not exist. Element def.: /[ANY]/Com/ComConfig


When does this happen:
-------------------------------------------------------------------
Always during configuration.

In which configuration does this happen:
-------------------------------------------------------------------
In all configurations without the module Com.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097564</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Non defined function referenced in DEM Code</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The DEM code cannot compile.

Typical compiler error explanations may be:
error C2064 and error C2100 in Visual C compiler.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
Dem ClearDTC notifications (/MICROSAR/Dem/DemGeneral/DemEventMemorySet/DemClearDTCNotification) are configured. 
AND
ONE or MORE notifications with /MICROSAR/Dem/DemGeneral/DemEventMemorySet/DemClearDTCNotification/DemClearDtcNotificationTime = START are configured
AND 
NO notifications with /MICROSAR/Dem/DemGeneral/DemEventMemorySet/DemClearDTCNotification/DemClearDtcNotificationTime = FINISH are configured</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Also configure a notifications with /MICROSAR/Dem/DemGeneral/DemEventMemorySet/DemClearDTCNotification/DemClearDtcNotificationTime = FINISH
You only need to provide an empty implementation of this notification.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>13.02.00</firstAffectedVersion>
         <versionsFixed>14.03.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097512</identifier>
         <package>If_AsrIfFr</package>
         <subpackage>Doc_TechRef</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Outdated single controller limitation</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Although multiple FlexRay Controllers are now supported, some parts of the technical reference still mention this limitation.

For example, the text "For the parameter FrIf_CtrlIdx only the value 0 is allowed" can be found several times under the API Description chapter.

Note: The outdated limitation can also be found in some comments in the implementation. For example, the text "Multiple FlexRay CCs are currently not supported, so no index translation is required" appears several times.


When does this happen:
-------------------------------------------------------------------
Always and immediately.


In which configuration does this happen:
-------------------------------------------------------------------
All of them.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Ignore the limitation, since multiple FlexRay controllers are supported.

Resolution:
-------------------------------------------------------------------
Not yet available</resolutionDescription>
         <firstAffectedVersion>4.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00066621</identifier>
         <package>GenTool_CsAsrLegacyDb2SystemDescr</package>
         <subpackage>Application</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BAC4: Temporary PNC ID for partial network ANHAENGERBETRIEB</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The PNC ID of the partial network ANHAENGERBETRIEB is unkown yet. For this reason, a temporary ID 23 hat been set.


When does this happen:
-------------------------------------------------------------------
The temporary ID is used if a Fibex file contains signals for the ANHAENGERBETRIEB PNC.


In which configuration does this happen:
-------------------------------------------------------------------
The ANHAENGERBETRIEB PNC is used for BMW PWF (Parken Wohnen Fahren) configurations.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
TBD</resolutionDescription>
         <firstAffectedVersion>1.05.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097061</identifier>
         <package>If_AsrIfFr</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>"FrTSyn_RxIndication" is wrongly shown as Rx indication function</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
"FrTSyn_RxIndication" is wrongly shown as Rx indication function (FrIfRxIndicationName) for FrIfRxPdus where FrIfUserRxIndicationUL is set to "NONE".

NOTE: This is just a display problem.


When does this happen:
-------------------------------------------------------------------
Always and immediately.


In which configuration does this happen:
-------------------------------------------------------------------
This happens in configurations were a FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfRxPdu has the parameter FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfRxPdu/FrIfUserRxIndicationUL set to "NONE" and the parameter FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfRxPdu/FrIfRxIndicationName exists.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
If the parameter FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfRxPdu/FrIfUserRxIndicationUL is set to NONE, the value of FrIfRxIndicationName can be ignored, since no Rx indications are given for FrIfRxPdus.


Resolution:
-------------------------------------------------------------------
Not yet available.</resolutionDescription>
         <firstAffectedVersion>4.01.02</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096774</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Duplicated variable definitions in analyzer stubs</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compilation in RTE Analyzer fails because the analyzer stubs contain multiple variable declarations with the same name.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when the indirect API is configured.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.09.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096982</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>AssertionError: The getMaxUnsignedValueForNumBytes utility allows only up to 4 bytes!</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The DCM generator invokes assertion with message: "The getMaxUnsignedValueForNumBytes utility allows only up to 4 bytes!"


When does this happen:
-------------------------------------------------------------------
Each and every time DCM configuration shall be generated.

In which configuration does this happen:
-------------------------------------------------------------------
- One of the following diagnostic services is to be handled within DCM: 0x23 (ReadMemoryByAddress), 0x2C 0x02 (DynamicallyDefineIdentifier by MemoryAddress) or 0x3D (WriteMemoryByAddress) (in Dcm_Cfg.h: DCM_SVC_XX_SUPPORT_ENABLED == STD_ON for any XX ={23, 2C, 3D}
AND
- The memory layout shall not be capable of supporting MID (MemoryID) (ECUC parameter: /Dcm/DcmConfigSet/DcmDsp/DcmDspMemory/DcmDspUseMemoryId == FALSE)
AND
- The user has defined a custom ALFID (AddressAndLengthFormatIDentifier) values, with more than four byte address (ECUC parameter: /Dcm/DcmConfigSet/DcmDsp/DcmDspMemory/DcmDspMemoryAddressAndLengthFormatIdentifier/DcmDspMemorySupportedAddressAndLengthFormatIdentifier has any values of the kind: 0x25, 0x45 or any 0xX5). 

Note: The affected configuration is invalid and shall be rejected by a validation followed by a meaningful explanation.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Since the affected configuration is invalid i.e. without MID the maximum address size cannot exceed four bytes, either enable MID support or reduce the address size.



Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.02.00</firstAffectedVersion>
         <versionsFixed>9.00.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00087958</identifier>
         <package>Os_CoreGen7</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Wrong return value of GetTaskState when called from PostTaskHook</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
GetTaskState returns SUSPENDED for current task when called from PostTaskHook.
Return 'RUNNING' instead.

When does this happen:
-------------------------------------------------------------------
In PostTaskHook the task is still running. 


In which configuration does this happen:
-------------------------------------------------------------------
Configuration invariant.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Do not use the API GetTaskState for the current task in the PostTaskHook.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096581</identifier>
         <package>Gw_AsrPduRCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>PduRTxBuffer references are incorrectly validated for transport protocol 1:N/N:1 routing paths with API forwarding PduRDestPdu</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A validation error PDUR10501 is shown incorrectly for PduRDestPdus which are API Forwardings.:
PDUR10501	All PduRDestTxBufferRefs of gateway PduRDestPdus have to reference the same PduRTxBuffers for a 1:N/N:1 transport protocol routing path.

When does this happen:
-------------------------------------------------------------------
The error message is always shown for PduRDestPdus mentioned below. The message is shown during live validation in the DaVinci Configurator 5.

In which configuration does this happen:
-------------------------------------------------------------------
The incorrect validation message is shown for either:
- 1:N transport protocol routings with a PduRDestPdu which is a API Forwarding
- N:1 transport protocol routings with a PduRDestPdu which is a API Forwarding

The message is only shown if the API Forwarding does not reference the same PduRTxBuffers like the Gateway PduRDestPdus (which is the correct configuration).</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Set the same PduRTxBuffers for the API Forwarding PduRDestPdu as for the Gateway PduRDestPdus. 
Another validation error 'PDUR11500	The PduRDestTxBufferRef PduRDestTxBufferRef(value=XXXXX) must only be configured for gateway routing paths.' is shown. Set the PduRDestTxBufferRef parameter for the API Forwarding PduRDestPdu to user defined. The error will be reduced to a warning. It does not affect the generation of the PduR.



Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>11.01.00</firstAffectedVersion>
         <versionsFixed>13.00.00, 12.01.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097148</identifier>
         <package>SysService_Asr4WdM</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>WdgMGlobalStateChangeCbk / WdgMLocalStateChangeCbk function prototype generated with incompatible signature compared to RTE</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The WdgMGlobalStateChangeCbk / WdgMLocalStateChangeCbk function prototype gets generated by the WdgM generator (in WdgM_PBcfg.h) even if the Service Port is connected and the Server Runnable is created and the prototype is already generated by Rte (in Rte_WdgM_&lt;Application name referenced from WdgMGlobalMemoryAppTaskRef&gt;.h).

In addition the signature of the prototypes of WdgM does not match the prototypes defined by the Swc template. The Rte generates Std_ReturnType as return value, the WdgM void. This is because the swc-files contains the erroneous return value (E_NOT_OK) instead of no return value.


When does this happen:
-------------------------------------------------------------------
At compiling time.


In which configuration does this happen:
-------------------------------------------------------------------
When WdgMGlobalStateChangeCbk / WdgMLocalStateChangeCbk is configured and Rte is used (WdgMUseRte==true).</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Follow the description of parameter /MICROSAR/WdgM/WdgMConfigSet/WdgMMode/WdgMGlobalStateChangeCbk and /MICROSAR/WdgM/WdgMGeneral/WdgMSupervisedEntity/WdgMLocalStateChangeCbk of BSWMD version 6.01.01.

The following description are in this version:
--------------------------------------
Callback function for notifying Watchdog Manager global status change.

Note:
If WdgMUseRte is configured as true and thus the receiver of the callback is an application above the RTE, the the user has to configure this parameter with the name of a C function which shall be called by WdgM. Within a separate file where this function is defined the user has to include the corresponding Rte application header file and call the Rte function. The Rte function is named according the following convention:
Rte_Call_WdgM_&lt;OsApplicationName&gt;_globalStateChangeCbk_Core&lt;CoreAssignment&gt;_GlobalStatusCallback
where OsApplicationName is entry in WdgMGlobalMemoryAppTaskRef
and CoreAssignment is the entry in WdgMModeCoreAssignment.

If WdgMGlobalMemoryAppTaskRef is not configured, the following pattern has to be applied:
Rte_Call_WdgM_globalStateChangeCbk_Core&lt;CoreAssignment&gt;_GlobalStatusCallback
where CoreAssignment is the entry in WdgMModeCoreAssignment.

Only if this naming convention is followed, the API of the RTE can be used within the callback.

--------------------------------------

Callback function for notifying the supervised entity's status change.

Note:
If WdgMUseRte is configured as true and thus the receiver of the callback is an application above the RTE, the the user has to configure this parameter with the name of a C function which shall be called by WdgM. Within a separate file where this function is defined the user has to include the corresponding Rte application header file and call the Rte function. The Rte function is named according the following convention:
Rte_Call_WdgM_&lt;OsApplicationName&gt;_localStateChangeCbk_&lt;SupervisedEntityName&gt;_LocalStatusCallback
where OsApplicationName is entry in WdgMGlobalMemoryAppTaskRef of the relating WdgMMode
and SupervisedEntityName is the entry in WdgMSupervisedEntity.

If WdgMAppTaskRef is not configured, the following pattern has to be applied:
Rte_Call_WdgM_localStateChangeCbk_&lt;SupervisedEntityName&gt;_LocalStatusCallback
where SupervisedEntityName is the entry in WdgMSupervisedEntity.

Only if this naming convention is followed, the API of the RTE can be used within the callback.
"


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097683</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>A generated value is not in range of the specified datatype</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
An error is reported in the configurator with following error message:
COM90500	The value 122040 with comment () is not in the range of the specified datatype UINT_16.

When does this happen:
-------------------------------------------------------------------
During generation of COM

In which configuration does this happen:
-------------------------------------------------------------------
In configurations in which any generated table has more than 65535 entries
AND
/PduR/PduRBswModules/PduRTransportProtocol for COM is set to FALSE</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
1) Use LdCom instead of COM for large PDUs

or

2) Enable /ActiveEcuC/PduR/Com[1:PduRTransportProtocol] and configure one Dummy TP PDU


Resolution:
-------------------------------------------------------------------
No modification of code as it would cause performance problems and use a lot of RAM, especially in Post-Build configurations.</resolutionDescription>
         <firstAffectedVersion>3.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096922</identifier>
         <package>Il_AsrSecOC</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Asynchronous MAC Generation/Verification not possible if CSM does not support the callback according SWS_Csm_00455</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler error occurs if Csm expects callback interfaces according SWS_Csm_00970 with two parameters (Crypto_JobType* job, Csm_ResultType result)
SecOC provideds a callback according SWS_Csm_00455 with 1 parameter (Std_ReturnType Result)

When does this happen:
-------------------------------------------------------------------
Always during compile time is configuration is as described below:

In which configuration does this happen:
-------------------------------------------------------------------
SecOC uses an asynchronous Csm Job.
AND 
CSM does not support callback according SWS_Csm_00455
AND 
Not CSM 4.2. is used.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Use CSM in synchronous mode.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.00.00</firstAffectedVersion>
         <versionsFixed>7.00.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096629</identifier>
         <package>SysService_AsrDet</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Linker error: unresolved symbol error for not existing callout function referenced in Det_Cfg.o in case of disabled DET</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
If the DET is disabled and a callout funtion is configured which does not exist an unresolved symbol error is thrown by the linker.

When does this happen:
-------------------------------------------------------------------
The error is issued by the linker during linking of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
The issue occurs if all of the following conditions apply:
1) The DET is disabled by setting DetEnableDet = false
AND
2) One or more callout functions are configured, e.g. DetErrorHook, DetReportRuntimeErrorCallout or DetReportTransientFaultCallout
AND
3) At least one of the configured callout functions does not exist</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The following workarounds are possible: 
1) In order to disable the DET remove it from the configuration.
2) Don't link Det_Cfg.o in case DET is disabled in your configuration.
3) Provide the configured callout functions also for a disabled DET.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>10.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096634</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Missing transformationBuffer variable when using implicit communication</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compilation fails because the RTE accesses a variable transformationBuffer_0 that is not available.
Compiler error: undeclared identifier.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when the configuration contains senders that use implicit communication with data element
invalidation enabled and data transformation is used.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.13.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00092955</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: incompatible types - from 'const &lt;MSN&gt;_PCConfigType *' to 'const &lt;MSN&gt;ConfigType *const</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The compiler throws an error like the following:

1&gt;  EcuM_Init_Cfg.c
1&gt;GenData/EcuM_Init_Cfg.c(86): error C4133: 'initializing' : incompatible types - from 'const CanNm_PCConfigType *' to 'const EcuM_PbConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(87): error C4133: 'initializing' : incompatible types - from 'const EcuM_PCConfigType *' to 'const SchM_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(88): error C4133: 'initializing' : incompatible types - from 'const SchM_ConfigType *' to 'const Can_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(89): error C4133: 'initializing' : incompatible types - from 'const Can_PCConfigType *' to 'const CanIf_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(90): error C4133: 'initializing' : incompatible types - from 'const CanIf_PCConfigType *' to 'const Com_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(91): error C4133: 'initializing' : incompatible types - from 'const Com_PCConfigType *' to 'const PduR_PBConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(92): error C4133: 'initializing' : incompatible types - from 'const PduR_PCConfigType *' to 'const CanSM_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(93): error C4133: 'initializing' : incompatible types - from 'const CanSM_PCConfigType *' to 'const CanNm_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(103): error C4133: 'initializing' : incompatible types - from 'const CanNm_PCConfigType *' to 'const EcuM_PbConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(104): error C4133: 'initializing' : incompatible types - from 'const EcuM_PCConfigType *' to 'const SchM_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(105): error C4133: 'initializing' : incompatible types - from 'const SchM_ConfigType *' to 'const Can_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(106): error C4133: 'initializing' : incompatible types - from 'const Can_PCConfigType *' to 'const CanIf_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(107): error C4133: 'initializing' : incompatible types - from 'const CanIf_PCConfigType *' to 'const Com_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(108): error C4133: 'initializing' : incompatible types - from 'const Com_PCConfigType *' to 'const PduR_PBConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(109): error C4133: 'initializing' : incompatible types - from 'const PduR_PCConfigType *' to 'const CanSM_ConfigType *const '
1&gt;GenData/EcuM_Init_Cfg.c(110): error C4133: 'initializing' : incompatible types - from 'const CanSM_PCConfigType *' to 'const CanNm_ConfigType *const '


When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
In variant configurations with modules which uses different EcuC init phases in different variants (/MICROSAR/EcuC/EcucGeneral/BswInitialization/InitFunction/InitPhase).

E.g. 
VARIANT_1: InitPhase = NO_INIT
VARIANT_2: InitPhase = INIT_TWO_MCAL</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
To resolve this the content of theCONT EcuM_GlobalConfigRoot in EcuM_Init_Cfg.c has to be reordered to fit to the struct EcuM_GlobalConfigRootType.

e.g.
CONST(EcuM_GlobalConfigRootType, ECUM_CONST) EcuM_GlobalConfigRoot =
{
  {
    BswM_Config_CanNm_Ptr, 
    EcuM_Config_CanNm_Ptr, 
    CanNm_Config_CanNm_Ptr, 
  }, 
  {
    BswM_Config_ClassB_Ptr, 
    CanNm_Config_ClassB_Ptr,    &lt;===== Wrong position, must be the last one
    EcuM_Config_ClassB_Ptr, 
  }, 
  {
    BswM_Config_ClassC_Ptr, 
    CanNm_Config_ClassC_Ptr,    &lt;===== Wrong position, must be the last one
    EcuM_Config_ClassC_Ptr,
  }
};

typedef struct
{
  CONSTP2CONST(BswM_ConfigType, TYPEDEF, BSWM_INIT_DATA) CfgPtr_BswM_Init;
  CONSTP2CONST(EcuM_PbConfigType, TYPEDEF, ECUM_INIT_DATA) CfgPtr_EcuM_Init;
  CONSTP2CONST(CanNm_ConfigType, TYPEDEF, CANNM_INIT_DATA) CfgPtr_CanNm_Init;
} EcuM_GlobalPCConfigType;



Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00098068</identifier>
         <package>Rte_Asr4</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Null pointer exception when a service dependency contains an invalid pim reference</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE generator aborts with a null pointer exception.


When does this happen:
-------------------------------------------------------------------
During generation.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when the configuration contains incomplete service dependencies e.g.
                            &lt;ROLE-BASED-DATA-ASSIGNMENT&gt;
                              &lt;ROLE&gt;ramBlock&lt;/ROLE&gt;
                              &lt;USED-DATA-ELEMENT/&gt;
                            &lt;/ROLE-BASED-DATA-ASSIGNMENT&gt;

instead of

                            &lt;ROLE-BASED-DATA-ASSIGNMENT&gt;
                              &lt;ROLE&gt;ramBlock&lt;/ROLE&gt;
                              &lt;USED-DATA-ELEMENT&gt;
                                &lt;LOCAL-VARIABLE-REF DEST="VARIABLE-DATA-PROTOTYPE"&gt;/path/to/pim&lt;/LOCAL-VARIABLE-REF&gt;
                              &lt;/USED-DATA-ELEMENT&gt;
                            &lt;/ROLE-BASED-DATA-ASSIGNMENT&gt;</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Configure a valid reference.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.00.00</firstAffectedVersion>
         <versionsFixed>4.18.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097876</identifier>
         <package>SysService_Asr4BswMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Generated data streams toggle with each code generation if &lt;MSN&gt;ReduceDataByStreaming is enabled</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Generated Code has to be recompiled or added again to the Users CMS because
the order in streamed CONST arrays is not deterministic and changes by chance with each code generation.

When does this happen:
-------------------------------------------------------------------
At generation time.

In which configuration does this happen:
-------------------------------------------------------------------
Any configuration where &lt;MSN&gt;ReduceDataByStreaming returns true.</problemDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096007</identifier>
         <package>EcuAb_AsrIoHwAb</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>IoHwAb - Init Values not configurable for complex data type (e.g Array, structure...)</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
No Init-Value for configured complex Data Type could be set.

When does this happen:
-------------------------------------------------------------------
when a data type is created by the user and he wants to set a Init Value on the port prototype


In which configuration does this happen:
-------------------------------------------------------------------
Every configuration with IoHwAb and with Data Types != from base types</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Currently, for Arrays and Records no initial values can be configured. So a user has to connect a port with a data element referencing an array or a record always with the counterpart in an application within the DaVinci Developer.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>6.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096615</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>RTE Analyzer fails due to duplicated runnable functions</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Rte Analyzer aborts with error message:
ERROR: Linking globals named 'Dem_GetEventUdsStatus': symbol multiply defined!


When does this happen:
-------------------------------------------------------------------
The error is issued by RTE Analyzer during compilation of the code in case the configuration is as described below.


In which configuration does this happen:
-------------------------------------------------------------------
This happens when the configuration contains multiple service components with different names and
the same runnable entity symbol.
Moreover one service component needs to contain different runnables with the same symbol.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Remove the implementation of the regarded service component runnable from all but one RteAnalyzer stubs.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.09.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096559</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Wrong signal type for data conversion</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The COM module reports that the signal data type is invalid.


When does this happen:
-------------------------------------------------------------------
After the RTE generator run in the calculation phase.


In which configuration does this happen:
-------------------------------------------------------------------
This happens when data conversion for COM signals is configured.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Set the signal type parameter to user defined and select the value that is expected by COM.
In case the RTE generator selected SINT24 or UINT24 create type reference data types in the configuration
uint24 =&gt; uint32 
sint24 =&gt; sint32
and select SINT32 or UINT32 in the COM configuration.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.12.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097291</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Use of undeclared identifier Rte_Appl_AckFlags</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compilation fails because a Rte_Feedback API accesses Rte_Appl_AckFlags that do not exist.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when a signal is sent from a different partition than the partition that contains the COM and
when transmission acknowledgement is configured.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.02.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00092892</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: function "EcuM_BswErrorHook" has no prototype</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler throws the following error:

function "EcuM_BswErrorHook" has no prototype

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
Only in configurations with any PB Modules but EcuM is not configured as PB

AND 

The module which uses the API EcuM_BswErrorHook() includes 'EcuM.h' instead of 'EcuM_BswErrorHook.h'.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Include the file 'EcuM_Error.h' additional to the include 'EcuM.h', e.g. via a user configuration file.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096969</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Doc_TechRef</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Misleading function return code description for API Dcm_GetTesterSourceAddress</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
API Dcm_GetTesterSourceAddress always returns E_OK, even if the TesterSourceAddress has an invalid value.


When does this happen:
-------------------------------------------------------------------
At runtime, if invalid function arguments are passed (e.g. invalid DcmRxPduId, NULL pointer for the return value etc.)


In which configuration does this happen:
-------------------------------------------------------------------
This happens in all configurations where 
- Dev error detect is disabled with Dcm/DcmConfigSet/DcmGeneral/DcmDevErrorDetect (DCM_DEV_ERROR_DETECT == STD_OFF)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Consider the E_NOT_OK return value to be returned only under following condition DCM_DEV_ERROR_DETECT == STD_ON.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.02.00</firstAffectedVersion>
         <versionsFixed>9.03.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097303</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Call to job finished runnable misses parameters</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compilation fails because a task calls a notify job finished runnable without arguments.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when an NvBlock SWC is configured and when the NvM_MainFunction and the job finished runnable are mapped to different tasks.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Do not map the job finished runnable to a task.
It will then be executed in the context of the task that schedules NvM_MainFunction.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.08.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00092622</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>A change of the main function period does not lead to a rebuild of the SWC description</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The SWC description file is not updated after a change of the EcuM main function period. 

When does this happen:
-------------------------------------------------------------------
After change of the parameter /MICROSAR/EcuM/EcuMGeneral/EcuMMainFunctionPeriod.

In which configuration does this happen:
-------------------------------------------------------------------
In all configurations.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Adapt another parameter which leads to a rebuild of the SWC description, e.g. rename of a sleepmode [/EcuM/EcuMConfiguration/EcuMCommonConfiguration/EcuMSleepMode].

After rebuild the name of this sleepmode can be switched back to the old name, the rename is only necessary to trigger a rebuild.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00094612</identifier>
         <package>SysService_Asr4WdM</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>WdgM_GetTickCount is called with suspended interrupts</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
WdgM_GetTickCount is called with suspended interrupts. If the timebase source is configured to be an Os counter, this results in an error. It is not allowed to call Os-APIs with suspended interrupts. The consequence is that the Os will run in error hook and will shutdown.


When does this happen:
-------------------------------------------------------------------
Always and immediately if an Os Counter is used as timebase.


In which configuration does this happen:
-------------------------------------------------------------------
/MICROSAR/WdgM/WdgMGeneral/WdgMTimebaseSource == WDGM_OS_COUNTER_TICK</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Implement WDGM_EXCLUSIVE_AREA_0 with an OS resource and assign all tasks to this resource, to which the following runnable/schedulabe entities are mapped:
- WdgM_Init
- WdgM_MainFunction
- All runnables calling any CheckpointReached operation


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>5.02.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096830</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: undeclared identifier retTransformer</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compilation fails because the compiler reports the usage of an undeclared identifier retTransformer inside Rte_ComSendSignalProxyPeriodic.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
fan-out scenario
signal specific transformation
e2e protection
write from non bsw partition</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.04.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00088219</identifier>
         <package>SysService_AsrCal</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>CAL90005	Generator (MICROSAR Cal Generator) failure, because of an exception</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Cal throws exception:

CAL90005	Generator (MICROSAR Cal Generator) failure, because of an exception (1 message)
	CAL90005	Exception in Cal generator during Validation encountered: 
com.vector.cfg.gen.core.utils.exceptions.GeneralParameterException: AtomicBitAccessableInBitfield could not be resolved. No EcuC or Board Module was found.
		/ActiveEcuC/Cal



When does this happen:
-------------------------------------------------------------------
if parameter /ActiveEcuC/EcuC/EcucGeneral[AtomicVariableAccess] is not configured


In which configuration does this happen:
-------------------------------------------------------------------
if parameter /ActiveEcuC/EcuC/EcucGeneral[AtomicVariableAccess] is not configured</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.02.01</firstAffectedVersion>
         <versionsFixed>4.00.01</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097534</identifier>
         <package>Il_AsrIpduMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Exception IpduM90005 is thrown</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Validation View shows message IpduM90005
Generation is aborted
    

When does this happen:
-------------------------------------------------------------------
during generation


In which configuration does this happen:
-------------------------------------------------------------------
any configuration with more than one different global pdu reference in one routing path</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>8.00.00</firstAffectedVersion>
         <versionsFixed>8.00.01</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00072123</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Dcm violates DCM796: ReadDataLength has two arguments if DcmDspDataUsePort configured to USE_DATA_ASYNCH_CLIENT_SERVER</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Actual version of DCM differs operation arguments for operation ReadDataLength depending on parameter DcmDspDataUsePort. For DcmDspDataUsePort configured to USE_DATA_ASYNCH_CLIENT_SERVER ReadDataLength is generated with following arguments:
In Dcm_OpStatusType OpStatus, Out UInt16 DataLength

For DcmDspDataUsePort configured to USE_DATA_SYNCH_CLIENT_SERVER ReadDataLength is generated with argument Out UInt16 DataLength, which is correct.

This violates following AUTOSAR Requirement:

Dcm796
Service name:  Length  Xxx_ReadData
Syntax: Std_ReturnType Xxx_ReadDataLength( 
    uint16* DataLength 
) 
Service ID[hex]:  0x36 
Sync/Async:  Synchronous 
Reentrancy:  Non Reentrant 
Parameters (in):  None 
Parameters (inout):  None 
Parameters (out):  DataLength  Length of the data to be writen/read 
Return value:  Std_ReturnType  E_OK: this value is always returned. 
Description:   data length of a Data.  This function requests the application to return the

AUTOSAR does not differ between Asynch and synchronous for configured for parameter DcmDspDataUsePort


When does this happen:
-------------------------------------------------------------------
For DID with variable Length and DcmDspDataUsePort configured to USE_DATA_ASYNCH_CLIENT_SERVER


In which configuration does this happen:
-------------------------------------------------------------------
For DID with variable Length and DcmDspDataUsePort configured to USE_DATA_ASYNCH_CLIENT_SERVER/USE_DATA_ASYNCH_FNC</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Use synchronous client server/ call out function DID data ports.



Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.02.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096516</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Wrong generated Rte_IocSend calls for queued communication</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler reports unresolved symbols, like Rte_IocSend_&lt;Identifier&gt;.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This happens for configurations with queued sender/receiver N:1 communication over partition boundaries, when all senders are mapped to the same OsApplication an "Enforce IOC" (Microsar Parameter) is not set.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Add an addition sender which is mapped to another OsApplication than the other senders.
OR 
Use a PR-Port instead of a R-Port on receiving side.
OR 
Activate "Enforce IOC" parameter.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.03.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00094319</identifier>
         <package>SysService_Asr4BswMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Auto-Configuration Communication Control: Init Mode of Lin Schedule Indication is missing</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A validator in Cfg5 reports the following warning:

BSWM01057       Init Mode of CC_LinScheduleIndication_&lt;Schedule Name&gt; is not known.
                Set BswMBswModeInitValueMode(value=) to LinSMConf_LinSMSchedule_&lt;NAME&gt;
/ActiveEcuC/BswM/BswMConfig/BswMArbitration/CC_LinScheduleIndication_LIN00_&lt;Schedule_Name&gt;/BswMModeInitValue/BswMBswModeInitValue[BswMBswModeInitValueMode]
                /ActiveEcuC/BswM/BswMConfig/BswMArbitration/CC_LinScheduleIndication_LIN00_&lt;Schedule_Name&gt;



When does this happen:
-------------------------------------------------------------------
Always after configuring the Auto-Configuration Communication Control.


In which configuration does this happen:
-------------------------------------------------------------------
Only in configurations with at least one Lin channel 

AND 

Auto-Configuration Communication Control is configured.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Set the normal schedule via the provided solving action.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>10.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097168</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>EcuM debug data cannot be found in the map file</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
During A2L update several symbols of EcuM (that the EcuM generator actually registers through the CFG5 McData Service Interface) cannot be found in the map file.
EcuM_ExpiredWakeups
EcuM_PendingCheckWakeups
EcuM_PendingWakeups

When does this happen:
-------------------------------------------------------------------
After compilation when  the A2L / calibration workflow is used to generate a complete A2L file with addresses of the target.

In which configuration does this happen:
-------------------------------------------------------------------
Whenever generation of Debug Data is enabled in DaVinci Configurator and EcuM is used.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097649</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Rte_Write writes a variable that does not exist</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The compiler states: undeclared identifier

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
- LdCom is used with external Signal
- Write from non bsw partition
- Data transformation is disabled</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Create another receiver port in the same component as the LdCom sender port and connect it the LdCom sender port.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.09.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097856</identifier>
         <package>DrvFr_XErayAsr</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>[Error] PostBuildXmlGen50009 - Symbol Fr_NumberOfCtrlRegs not accessible via root structure(s) (missing references).</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The PostBuildXml generator throws the following errors:

[Error] PostBuildXmlGen50009 - Symbol Fr_NumberOfCtrlRegs not accessible via root structure(s) (missing references).
[Error] PostBuildXmlGen50009 - Symbol Fr_NumberOfCcBufs not accessible via root structure(s) (missing references).
[Error] PostBuildXmlGen50009 - Symbol Fr_CtrlRegs not accessible via root structure(s) (missing references).
[Error] PostBuildXmlGen50009 - Symbol Fr_CcBufs not accessible via root structure(s) (missing references).

When does this happen:
-------------------------------------------------------------------
Always and immediately during generation of the PB hex file.

In which configuration does this happen:
-------------------------------------------------------------------
In all POST-BUILD-LOADABLE configurations where only one FrController is configured.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
As workaround ignore the errors since they have no effects on the generated hex file of the FR.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.02.00</firstAffectedVersion>
         <versionsFixed>5.00.02</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00094770</identifier>
         <package>Security_AsrCsm</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Csm_GetSizeOfJob() macro definition is missing if no job is configured</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
When no job is configured, the Csm_GetSizeOfJob() macro is not being defined. 


When does this happen:
-------------------------------------------------------------------
This happens during compile time


In which configuration does this happen:
-------------------------------------------------------------------
This happens in all configurations when no job is configured</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Configure at least one job.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00074983</identifier>
         <package>MSR_UserManual_Startup_Bmw_BAC4x</package>
         <subpackage>Doc_UserMan</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Necessary step to update a SIP is not documented</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
All the BAC Module Version parameters in container "CommonPublishedInformation" of each BAC-Module is not updated during SIP-Update.
This results in the fact that the module is generated with a wrong version.
Which results in compiler errors.

When does this happen:
-------------------------------------------------------------------
@ Compile time


In which configuration does this happen:
-------------------------------------------------------------------
If an existing Configuration is updated to a new SIP
&amp;&amp;
The BMW BAC-Module Version is changed</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
no Workaround
Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097087</identifier>
         <package>Rte_Asr4</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Null pointer exception when a data element is missing</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE generation aborts with a null pointer exception when a connection connects two ports with incompatible interfaces and when no port interface mapping is configured.

When does this happen:
-------------------------------------------------------------------
During generation.


In which configuration does this happen:
-------------------------------------------------------------------
This happens when</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Rename the data element or configure a port interface mapping.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.08.00</firstAffectedVersion>
         <versionsFixed>4.17.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097900</identifier>
         <package>Il_AsrSecOC</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>DET error occurs during reception CAN FD PDU</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
DET error in the function RxIndication occurs during runtime if a PDU is received that is greater than the configured Global PDU length of the secured PDU.
This can happen if the CAN diver added padding to the PDU.

When does this happen:
-------------------------------------------------------------------
during runtime.

In which configuration does this happen:
-------------------------------------------------------------------
If Secured PDUs are received by CAN FD
AND 
the configured Secured PDU Global PDU length is not a CAN FD length (... 8, 12, 16, 20, 24, 32, 48, 64)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Set the Global Pdu Length of the Secured PDU to the next valid CAN FD length (..., 8, 12, 16, 20, 24, 32, 48, 64)

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097450</identifier>
         <package>Security_AsrCsm</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Generator Error for SipHash Primitive</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Generator Error SipHash enum value is missing.

When does this happen:
-------------------------------------------------------------------
Always

In which configuration does this happen:
-------------------------------------------------------------------
If a primitive using SipHash is configured.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
To use SipHash:
1. Set GenerateAlgorithmFamily to CRYPTO_ALGOFAM_CUSTOM
2. Set "User Defined Value" for GenerateAlgorithmFamily
3. Set AlgorithmFamilyCustom to CRYPTO_ALGOFAM_SIPHASH


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.03.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00079070</identifier>
         <package>FblDrvFlash_Rh850Rv40His</package>
         <subpackage>Impl_Base</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>(Multi Core only) Reprogramable reset vector works only for CPU1</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Only Reset vector of CPU can be reprogrammed via provided API

When does this happen:
-------------------------------------------------------------------
Always and immediately

In which configuration does this happen:
-------------------------------------------------------------------
FLASH_ENABLE_SET_RESETVECTOR_API must be set</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.02.00</firstAffectedVersion>
         <versionsFixed>1.07.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097457</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Matrix dimensions are swapped for two dimensional arrays in A2L file</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A measurement tool displays rows as columns and columns as rows.

When does this happen:
-------------------------------------------------------------------
During measurement and calibration.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when the configuration contains arrays with two dimensions.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00094994</identifier>
         <package>Il_AsrSecOC</package>
         <subpackage>root</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: 'SecOC_GetAuthenticPduDataContainerAuthenticPduStartIdxOfRxPduInfo' undefined</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler error occurs

1&gt;..\..\..\..\BSW\SecOC\SecOC.c(1856): error C4013: 'SecOC_GetAuthenticPduDataContainerAuthenticPduStartIdxOfRxPduInfo' undefined; assuming extern returning int
1&gt;..\..\..\..\BSW\SecOC\SecOC.c(1857): error C4013: 'SecOC_GetAuthenticPduDataContainerAuthenticPduLengthOfRxPduInfo' undefined; assuming extern returning int
1&gt;..\..\..\..\BSW\SecOC\SecOC.c(1921): error C4013: 'SecOC_GetSecuredPduDataContainerAuthenticPduStartIdxOfRxPduInfo' undefined; assuming extern returning int

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.


In which configuration does this happen:
-------------------------------------------------------------------
IF on Rx side ONLY Rx Processings are configured with Authentic PDUs with the length 0.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Configure a dummy Rx Processing with a Authentic Pdu with a length != 0.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00092644</identifier>
         <package>Cdd_AsrCddCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>ConsistencyRT00002 after adding multiple ComStackContributions of the same type</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
ConsistencyRT00002 is thrown


When does this happen:
-------------------------------------------------------------------
1) you add an unnecessary ComStackContribution that voids the allowed multiplicity
2) you remove the unnecessary ComStackContribution by delete or undo to comply with the allowed multiplicity again
3) the above exception is thrown


In which configuration does this happen:
-------------------------------------------------------------------
Any configuration containing the module Cdd_AsrCddCfg5</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Restart CFG5 and the message is gone again.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00093413</identifier>
         <package>SysService_Asr4BswMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Auto Configuration Module Initialization - Changed User Include Files always restores</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
If the EcuM_Init_PBCfg.h entry in the User Config File (/MICROSAR/BswM/BswMGeneral/BswMUserIncludeFiles/BswMUserIncludeFile) list is overwritten by some other value or being replaced, it is being restored after the Module Configuration Auto Configuration is applied again and the other value might be removed.


When does this happen:
-------------------------------------------------------------------
During the configuration with DaVinci Configurator in the BSW Management Editor in the following sequence:
- Configure Module Initialization is clicked
- Finish is clicked
- One of the /MICROSAR/BswM/BswMGeneral/BswMUserIncludeFiles/BswMUserIncludeFile has the value EcuM_Init_PBCfg.h, this one is being changed or deleted.
- Configure Module Initialization is clicked once again
- Finish is clicked
- the dialog 'Manual Adaptions' does not pop up or it pops up but the change is not displayed
- Finish is clicked in the 'Manual Adaptions' dialog if it is displayed


In which configuration does this happen:
-------------------------------------------------------------------
Any configuration using the Module Initialization Auto Configurations in BSW Management in DaVinci Configurator

AND

EcuM is configured as Postbuild Loadable or Postbuild Selectable</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Redo the previously manual changes that have been overwritten.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.00.01</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097684</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Warning RTE49999 when XcpEvent support is enabled</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE generator prints a warning RTE49999 AST property is undefined.
Compilation fails because a task calls the XcpEvent API with the undfined identifier UNDEFINED.

When does this happen:
-------------------------------------------------------------------
During generation.

In which configuration does this happen:
-------------------------------------------------------------------
This happens when XcpEvent support is enabled and when a task contain only server runnables as executable entities.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Map the server runnables to another task that also contains runnables with different trigger.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096900</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: identifier EcuM_Get&lt;***&gt; not declared</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The compiler throws one of the following errors:

Compiler error: identifier EcuM_GetValidationTimeoutTable not declared
Compiler error: identifier EcuM_DecValidationTimeoutTable not declared
Compiler error: identifier EcuM_SetValidationTimeoutTable not declared
Compiler error: identifier EcuM_GetReasonOfWakeupSourceList not declared
Compiler error: identifier EcuM_GetChannelOfWakeupSourceList not declared


When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
In variant configurations
AND
At least one variant don't use parameter EcuMValidationTimeout | EcuMComMChannelRef | EcuMResetReasonRef (Value = 0 or not existent)
AND 
Another variant use parameter EcuMValidationTimeout | EcuMComMChannelRef | EcuMResetReasonRef</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Ensure that the parameters EcuMValidationTimeout | EcuMComMChannelRef | EcuMResetReasonRef are existent in all variants OR are not existent in all variants. But the existence for each of them has to be consistent over all variants.

It is sufficient to configure a dummy wakeup source which is not used by the code to ensure this.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>8.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097242</identifier>
         <package>If_AsrIfFr</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>FrIf debug data cannot be found in the map file</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
During A2L update several symbols of FrIf (that the FrIf generator actually registers through the CFG5 McData Service Interface) cannot be found in the map file.
FrIf_Status.CurrentCycle
FrIf_Status.CurrentJobNumber
FrIf_Status.JobListExecutionEnabled
FrIf_Status.State


When does this happen:
-------------------------------------------------------------------
After compilation when  the A2L / calibration workflow is used to generate a complete A2L file with addresses of the target.

In which configuration does this happen:
-------------------------------------------------------------------
Whenever generation of Debug Data is enabled in DaVinci Configurator and FrIf is used.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Since the FrIf_Status variable is now an array, manually edit the generated a2l file and add the index to all the FrIf_Status occurrences.

Take into account that the FrIf_Status array will contain 2 elements instead of one, if the macro FrIf_CommonMaxNumberOfClusters is not defined as 1.
 
Resolution:
-------------------------------------------------------------------
A resolution is not yet available.</resolutionDescription>
         <firstAffectedVersion>4.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097355</identifier>
         <package>SysService_Asr4BswMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Auto-Configuration Ecu State Handling: Self run request timeout value is not shown correct in case of 0</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The overview page of the Auto-configuration Ecu State handling does not show the correct value for the self run request timeout. Instead it shows the default value (0.1).


When does this happen:
-------------------------------------------------------------------
Always if the value is set to 0.


In which configuration does this happen:
-------------------------------------------------------------------
In all configurations with Auto-Configuration Ecu State Handling configured

AND 

Value of self run request timeout is set to 0.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>11.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00093405</identifier>
         <package>SysService_Asr4BswMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Auto Configuration - Invalid multiplicity after manual adaptations of container BswMAvailableActions</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
User-modifications about a changed BswMAvailableActions subcontainer are recognized by the Auto Configuration assistant but even if they should be kept, the assistant will re-create the original action. This leads to an invalid model because the user modification is not removed by the assistant.

Example:
- Configure Communication Control is used and Reinitialize TX is turned ON, Finish is clicked.
- the /MICROSAR/BswM/BswMConfig/BswMModeControl/BswMAction CC_EnableDM_&lt;I-PDU-Group&gt; has a BswMDeadlineMonitoringControl container which is deleted within the Basic Editor
- Instead another BswMAvailableActions subcontainer is created of another type, e.g. BswMComMModeLimitation
- Configure Communication Control is used once again and Finish is clicked. An option if offered to either keep this modification or to restore it, but independent of the choice, the original BswMDeadlineMonitoringControl is restored without removing the user modification. Because the user modification is not removed the multiplicity of the container BswMAvailableActions[0...1] is violated.


When does this happen:
-------------------------------------------------------------------
During the configuration with DaVinci Configurator in the BSW Management Editor in the following sequence:
- Configure &lt;Auto Configuration&gt; is clicked
- Finish is clicked
- Some objects like a /MICROSAR/BswM/BswMConfig/BswMModeControl/BswMAction/BswMAvailableActions/BswMDeadlineMonitoringControl container are deleted or changed
- Configure &lt;Auto Configuration&gt; is clicked once again
- Finish is clicked
- the dialog 'Manual Adaptions' does pop up 
- Finish is clicked in the 'Manual Adaptions' dialog 


In which configuration does this happen:
-------------------------------------------------------------------
Any configuration using one of the Auto Configurations in BSW Management in DaVinci Configurator</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Redo the previously manual changes that have been overwritten.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>10.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00092790</identifier>
         <package>Il_AsrIpduMCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Unused parts of a multiplexed PDU contain old data for non-aligned dynamic parts</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
A transmitted multiplex PDU with configured Unused Area Default Value contains
non-default values in unused areas.

The ECU continues to behave normally.


When does this happen:
-------------------------------------------------------------------
During transmission or triggertransmit of a multiplexed PDU.


In which configuration does this happen:
-------------------------------------------------------------------
Any configuration where two or more dynamic parts of the same multiplexed PDU
use different parts in the PDU, i.e. don't perfectly overlap.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Configure additional segments in IpduM and matching signals in Com with the
desired Unused Areas Default Value as initial values in Com so all dynamic parts
of a given multiplexed PDU completely overlap.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00091118</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>EcuM causes a Rte Det error (RTE_E_DET_UNINIT) in the shutdown sequence while the Nvm write all is performed</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The Rte throws a Det error with the ID RTE_E_DET_UNINIT during the shutdown sequence.


When does this happen:
-------------------------------------------------------------------
Always during the NvM_WriteAll() is performed.


In which configuration does this happen:
-------------------------------------------------------------------
Only in configurations with all the following parameters are set to true:

/ActiveEcuC/EcuM/EcuMGeneral/EcuMEnableFixBehavior
/ActiveEcuC/EcuM/EcuMFixedGeneral/EcuMModeSwitchRteAck
/ActiveEcuC/EcuM/EcuMFixedGeneral/EcuMIncludeNvramMgr
/ActiveEcuC/Rte/RteGeneration/RteDevErrorDetect</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The only workaround is to filter this DET message.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097086</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: Undefined reference to `Com_GetTxFilterInitValueArrayBasedFilterInitValueLengthOfTxSigInfo'</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compile error occurs in Function Com_TxSignal_EvaluateFilter:
Undefined reference to `Com_GetTxFilterInitValueArrayBasedFilterInitValueLengthOfTxSigInfo'

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
This error will occur in configuration, where
- Rx UINT8_N Signal/ Group Signal with a Filter exists (NEVER || MASKED_NEW_DIFFERS_MASKED_OLD)
AND
- At least one  Tx Signal /Group Signal with (Application Type != UINT8_N) with ( (Filter != ALWAYS) or (transferProperty == TRIGGERED_ON_CHANGE || TRIGGERED_ON_CHANGE_WITHOUT_REPETITION) ) exists
AND
- all Tx Signal /Group Signals with  (Application Type == UINT8_N) are configured without any Filter and without any OnChange-TransferProperty</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>9.00.00</firstAffectedVersion>
         <versionsFixed>14.00.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097686</identifier>
         <package>Security_AsrCsm</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error due to invalid Job structure</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compile error may rise due to missing jobId element in the Crypto_JobType when using other CryptoDriver´s then Vectors.
Also naming of the element length in Crypto_PrimitiveInfoType is incorrect and will lead to compiler error if a third party driver accesses it.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
Third party crypto drivers are used.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00079399</identifier>
         <package>Cdd_AsrCddCfg5</package>
         <subpackage>Description</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Linker error:  '&lt;Cdd&gt;_Transmit' : undeclared identifier</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Linker error in PduR_Lcfg.c:  '&lt;Cdd&gt;_Transmit' : undeclared identifier

The Cdd_AsrCddCfg5 is not derived according to the ASR 4.0.3 rules and allows a LOWER-MULTIPLICITY of 0 for the CddPduRLowerLayerRxPdu and CddPduRLowerLayerTxPdu instead of the LOWER-MULTIPLICITY of 1.
The generic ASR PduR according to the ASR 4.0.3 Specification has no information to deactivate a communication direction (e.g. a Parameter in the PduRBswModules).

When does this happen:
-------------------------------------------------------------------
The error is issued by the linker after compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
Rx only Cdd with a CddPduRLowerLayerContribution  (just receive pathways exits)

The &lt;CddName&gt;.h file contains the following define: 
&lt;CddName&gt;_LOWERLAYERCOMIF_TX  is defined to STD_OFF</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Implement the not required '&lt;Cdd&gt;_Transmit' API on your own in a c and h file of your choice and add the header file with a user config file to the PduR configuration that the compiler does not throw a warning.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097972</identifier>
         <package>Os_CoreGen7</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Linaro compiler selection does not generate correct define</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compilation aborts with an error:
Undefined or unsupported compiler


When does this happen:
-------------------------------------------------------------------
Always


In which configuration does this happen:
-------------------------------------------------------------------
Linaro GCC compiler is selected.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Define OS_CFG_COMPILER_LINARO via compiler options.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.13.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096582</identifier>
         <package>_3rdParty_McalIntegration_Helper</package>
         <subpackage>VectorIntegration</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Non-interactive Mode fails</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The non-interactive mode doesn't work: Running the batch file Script_MCAL_Prepare.bat (starts the 3rdParty MCAL Integration Helper tool) with the parameter --auto (providing a derivative) it is expected to finish the tool without user action. Instead a GUI window opens expecting a user action / dialog.


When does this happen:
-------------------------------------------------------------------
Starting the 3rdParty MCAL Integration Helper tool via Script_MCAL_Prepare.bat.


In which configuration does this happen:
-------------------------------------------------------------------
Any.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.</resolutionDescription>
         <firstAffectedVersion>2.02.01</firstAffectedVersion>
         <versionsFixed>2.02.03</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00094875</identifier>
         <package>If_AsrIfMem</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: dld.exe: warning: Undefined symbol 'MemIf_*_WriteWrapper' in file 'obj/MemIf_Cfg.o'</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler error: dld.exe: warning: Undefined symbol 'MemIf_*_WriteWrapper' in file 'obj/MemIf_Cfg.o' 

When does this happen:
-------------------------------------------------------------------
During linking the project

In which configuration does this happen:
-------------------------------------------------------------------
Windriver Diab compiler for PPC version is used  (tested with version 5.9.4.8)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Redefine MEMIF_LOCAL_INLINE to MEMIF_LOCAL (e.g. in Compiler_Cfg.h)

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>5.02.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097458</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: undefined symbol Dem_Event_GetTripCount</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Functions 'Dem_Data_CopyCyclesTestedSinceLastFailed' and 'Dem_Data_CopyHealingCounterDownwards' will not compile due to an undefined symbol 'Dem_Event_GetTripCount'.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
( (All events have Dem/DemConfigSet/DemEventParameter/DemEventClass/DemEventFailureCycleCounterThreshold &lt;= 1)
OR (Dem/DemGeneral/DemMultipleTripSupport == FALSE) )
AND 
(All events have no indicator (Dem/DemConfigSet/DemEventParameter/DemEventClass/DemIndicatorAttribute) configured OR an indicator with Dem/DemConfigSet/DemEventParameter/DemEventClass/DemIndicatorAttribute/DemIndicatorHealingCycleCounterThreshold &lt;= 1)
AND
(Using data elements DEM_CYCLES_TESTED_SINCE_LAST_FAILED or DEM_HEALINGCTR_DOWNCNT (Dem/DemGeneral/DemDataClass/DemDataElementInternalData) in an extended data record (Dem/DemGeneral/DemExtendedDataRecordClass) or Did (Dem/DemGeneral/DemDidClass) )
AND
(Any DTC has Extended Data Records (Dem/DemConfigSet/DemEventParameter/DemExtendedDataClassRef) or Snapshot Records (Dem/DemConfigSet/DemEventParameter/DemFreezeFrameClassRef) configured)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Create an internal dummy event referencing an indicator and Dem/DemConfigSet/DemEventParameter/DemEventClass/DemIndicatorAttribute/DemIndicatorHealingCycleCounterThreshold.

(Adding a dummy event with Dem/DemConfigSet/DemEventParameter/DemEventClass/DemEventFailureCycleCounterThreshold &gt; 1 will also remove the compile error, but the Dem won't calculate the data elements 'Cycles Tested Since Last Failed' and 'Healing Counter Inverted' correctly then, see ESCAN00097474).

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>13.04.00</firstAffectedVersion>
         <versionsFixed>14.02.00</versionsFixed>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097203</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: "conversion of data types, possible loss of data" in case of large buffers</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Following compiler errors might be reported:
Error: Dcm.c, line 36235: error C4244: '=' : conversion from 'Dcm_CfgNetBufferSizeMemType' to 'Dcm_DidMgrDidLengthType', possible loss of data
Error: Dcm.c, line 13586: error C4244: '=' : conversion from 'const Dcm_CfgDidMgrOptimizedDidLengthType' to 'uint16', possible loss of data
Error: Dcm.c, line 25946: error C4244: '=' : conversion from 'const Dcm_CfgDidMgrOptimizedDidLengthType' to 'Dcm_DidMgrDidLengthType', possible loss of data	

In many cases (dependent on compiler option settings) this might be reported as warning.

When does this happen:
-------------------------------------------------------------------
The error is issued by the compiler during compilation of the code in case the configuration is as described below.

In which configuration does this happen:
-------------------------------------------------------------------
- At least one DCM buffer is larger than 65535bytes ( ECUC parameter DcmDslBufferSize &gt; 65535)
AND
	- Service 0x22 (ReadDataByIdentifier) is handled within DCM (in Dcm_Cfg.h #define DCM_SVC_22_SUPPORT_ENABLED == STD_ON)
	OR
	- Service 0x2A (ReadDataByPeriodicIdentifier) is handled within DCM (in Dcm_Cfg.h #define DCM_SVC_2A_SUPPORT_ENABLED == STD_ON)
	OR
	- Service 0x2C (DynamicallyDefineDataByIdentifier) is handled within DCM (in Dcm_Cfg.h #define DCM_SVC_2C_SUPPORT_ENABLED == STD_ON)
	OR
	- Service 0x2F (InputOutputControlByIdentifier) is handled within DCM (in Dcm_Cfg.h #define DCM_SVC_2F_SUPPORT_ENABLED == STD_ON)

Note: Such buffer sizes are typically used in case of Bootloader applications.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Ignore the warning since no DID can have size of more than 16KB, since largest DcmDspDidDataPos can accept only up to 8KB and the largest DID signal can have only up to 8KB. So the largest DID can be a DID with a signal starting at position 8191 and having 8192 bytes. 



Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.03.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00096914</identifier>
         <package>Security_AsrCsm</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler error: CSM 4.2 deprecated APIs are not supported</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
SWCs, BSWs and CDDs using the old API will produce compiler errors regarding mismatching APIs.
The CsmUseDeprecated ECUC parameter has no functionality.

The AUTOSAR 4.3.0 specification is not fully compatible with the old AUTOSAR 4.2 APIs and behaviour. Therefore the Vector Informatik CSM 4.3 does not support backward compatible APIs (deprecated). 


When does this happen:
-------------------------------------------------------------------
This happens at compile time


In which configuration does this happen:
-------------------------------------------------------------------
This error occurs while mixing SWCs, BSWs or CDDs using AUTOSAR CSM 4.2 interface with the new CSM 4.3 interface.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Upgrade SWCs, CDDs or BSWs or downgrade the CSM.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00097519</identifier>
         <package>DrvCrypto_CryWrapper</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Validation Error: Csm shall include Crypto_30_CryWrapper_GeneratedTypes.h even if CryWrapper is not instantiated</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Validation "CRYPTO1007: Inclusion in Csm missing." occurs and shows issue that Crypto_30_CryWrapper_GeneratedTypes.h is not included by Csm even if CryWrapper is not used in configuration.

When does this happen:
-------------------------------------------------------------------
During configuration if Csm is instantiated in configuration but CryWrapper is not.

In which configuration does this happen:
-------------------------------------------------------------------
In configurations which instantiated Csm but not CryWrapper.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Simply executed the solving action (Add Crypto_30_CryWrapper_GeneratedTypes.h as include for Csm) and provide the path to the Crypto_30_CryWrapper_GeneratedTypes.h as include path to the used compiler. As an alterantive, an empty header could also be provided as long as CryWrapper shall not be used in this configuration.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.01.01</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00098057</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Generated data streams toggle with each code generation if &lt;MSN&gt;ReduceDataByStreaming is enabled</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Generated Code has to be recompiled or added again to the Users CMS because
the order in streamed CONST arrays is not deterministic and changes by chance with each code generation.

When does this happen:
-------------------------------------------------------------------
At generation time.

In which configuration does this happen:
-------------------------------------------------------------------
Any configuration where /ComReduceDataByStreaming returns true.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Configure ComReduceDataByStreaming to false if available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00078508</identifier>
         <package>FblDrvFlash_Rh850Rv40His</package>
         <subpackage>Impl_Base</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>[depends on derivative] Illegal flash block table configuration cause unintended block erase</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
If the code flash contains gaps where no flash exists and the user configure a flash block in this area, the flash driver will erase the next valid flash block (first block with start address bigger than the illegal configured block).


When does this happen:
-------------------------------------------------------------------
Always and immediately

In which configuration does this happen:
-------------------------------------------------------------------
all configurations, but not all derivatives

Note: The gap between user area and extended user area is not relevant. Until now, no known derivative is affected by this issue!</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Well configured flash block table, which corresponds to the real flash block structure.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>0.90.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00095571</identifier>
         <package>SysService_Asr4EcuM</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>EcuM causes a Rte warning about a not existing mode request type map</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
During validation the Rte throws the following warning:

Mode Declaration Group &lt;EcuM_Mode&gt; of Component &lt;EcuM&gt; has no mode request type map.
Each Mode Declaration Group used in the SW-C's ports has to have a unique mapping to an implementation data type. The Mode Group Data Type is set to &lt;uint8&gt;.

Help:
- define a mode request type map.


When does this happen:
-------------------------------------------------------------------
During validation of the Rte.


In which configuration does this happen:
-------------------------------------------------------------------
If /MICROSAR/EcuM/EcuMGeneral/EcuMEnableFixBehavior is set

OR 

If /MICROSAR/EcuM/EcuMFlexGeneral/EcuMModeHandling is set</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="apparentIssue">
         <identifier>ESCAN00089109</identifier>
         <package>Os_CoreGen7</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Software stack monitoring for non trusted functions not supported</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Stack monitoring in software is not supported for non trusted functions.

When does this happen:
-------------------------------------------------------------------
Always

In which configuration does this happen:
-------------------------------------------------------------------
In systems where non trusted functions and software stack checks are used:
In configuration:
/ActiveEcuC/Os/&lt;Application&gt;/OsApplicationNonTrustedFunction is used and /ActiveEcuC/Os/OsOS[OsStackMonitoring] = TRUE</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
If a MPU is available, protect stacks by MPU.
In case that no MPU is available, user has to ensure that stack overflow does not occur during execution of non trusted functions. Otherwise non trusted functions shall not be used.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00064376</identifier>
         <package>Cp_XcpOnFrAsr</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: cast increases required alignment of target type</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Please analyze warnings and decide wether a runtime impact can be ruled out.

Customer requests fix of following warning:
Line 2: ../../../external/BSW/FrXcp/FrXcp.c:1541: warning: [10348] cast increases required alignment of target type
	in FrXcp_MainFunctionRx:
	XcpCommand( (P2CONST(uint32, AUTOMATIC, FRXCP_APPL_DATA))&amp;FrXcp_ReceiveFrameCache[pduIdx].fc[XCP_FRAME_START] );

Background and filtered source:
\\vistrfs1\vgroup\PES\20_Sales\50_Order\5012000-5012999\5012865\CBD1200349_D00-Compiler_Warnings

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
Compiler
Version: 	Reading specs from D:/uti/Compiler/TriCore/GNU_3_4_5_8/bin/../lib/gcc/tricore/3.4.5/specs no tricore derivate specified set to -mcpu=tc12 Reading processor specific specs from D:/uti/Compiler/TriCore/GNU_3_4_5_8/bin/../lib/gcc/tricore/3.4.5/tricore.specs Reading specs from D:/uti/Compiler/TriCore/GNU_3_4_5_8/bin/../lib/gcc/tricore/3.4.5/tricore.specs
OptimizationOptions: 	-Os -pipe
AdditionalOptions: 	-x c -c -g -o obj\.o -nostartfiles -save-temps -DBRS_TIMEBASE_CLOCK=75 -DQUARTZ_CLOCK=20 -DEVA_BOARD_VEBN00211 -DGNU=1 -fno-common -mcpu=TC13-FPU_ERR13X_OP1 -fno-builtin -mwarnprqa=off -maligned-access -maligned-data-sections -I- -mno-warn-smalldata-initializers -msmall-pid -gdwarf-2
WarningOptions: 	-W -Wall -Wundef -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wnested-externs -Winline -Werror-implicit-function-declaration -Wmissing-noreturn
Assembler
Version: 	Reading specs from D:/uti/Compiler/TriCore/GNU_3_4_5_8/bin/../lib/gcc/tricore/3.4.5/specs no tricore derivate specified set to -mcpu=tc12 Reading processor specific specs from D:/uti/Compiler/TriCore/GNU_3_4_5_8/bin/../lib/gcc/tricore/3.4.5/tricore.specs Reading specs from D:/uti/Compiler/TriCore/GNU_3_4_5_8/bin/../lib/gcc/tricore/3.4.5/tricore.specs
AdditionalOptions: 	-Wa, -als -x assembler-with-cpp -Wundef -gdwarf-2 -c -nostartfiles -o obj\.o
Linker
Version: 	Reading specs from D:/uti/Compiler/TriCore/GNU_3_4_5_8/bin/../lib/gcc/tricore/3.4.5/specs no tricore derivate specified set to -mcpu=tc12 Reading processor specific specs from D:/uti/Compiler/TriCore/GNU_3_4_5_8/bin/../lib/gcc/tricore/3.4.5/tricore.specs Reading specs from D:/uti/Compiler/TriCore/GNU_3_4_5_8/bin/../lib/gcc/tricore/3.4.5/tricore.specs
AdditionalOptions: 	-o TsiStandard.elf -Xlinker -Map -Xlinker TsiStandard.map -mcpu=TC13-FPU_ERR13X_OP1 -nostartfiles --no-demangle --cref -LD:\uti\Compiler\TriCore\GNU_3_4_5_8\lib -LD:\uti\Compiler\TriCore\GNU_3_4_5_8\tricore\lib --start-group -lgcc -los --end-group -Xlinker -T -Xlinker TsiStandard.ld
Librarian
Version: 	GNU ar version 2.13 (tricore) using BFD version 2.13 (2008-12-10)
Flags: 	-rvsc makesupport.xml
 
// If the warning will never be resolved, explain the background. Else remove the text block and fix the warning.
Hint:
-------------------------------------------------------------------
The compiler warning is known and has been analyzed thoroughly for its impact on the code. Nevertheless it will not be fixed due to XXXXXXXX ADD REASON HERE XXXXXXXX</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround required as correct alignment is guaranteed by the GenTool option "Frame Alignment".


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.07.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00067159</identifier>
         <package>MemService_AsrNvM</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: cast truncates constant value</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------

&gt;..\..\bsw\nvm\nvm_crc.c(229) : warning C4310: cast truncates constant value

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
CANoeEmu + VS2008
It depends on definition of uint16_least: Warning occures only if uint16_least is not of type int.

 
Hint:
-------------------------------------------------------------------
The compiler warning is known and has been analyzed thoroughly for its impact on the code. Nevertheless it will not be fixed, because the cast confirms and enforces this behavior (i.e. the value SHALL be truncated, if necessary).
Additionally: Why uint16_least is not (unsigned) int? -&gt; this data type fulfills all requirements on a 16 bit unsigned value...</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround necessary.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.08.01</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00096913</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: Static function 'Rte_QUnqueueElementCallbackSpecific&lt;OsApplicationName&gt;()' is not used within this translation unit</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler warns for an unused function. 

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
On a partitioned or multicore system with fanin queued communication at least on one partition/core and no queued communication on another partition/core.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.04.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00090806</identifier>
         <package>Gw_AsrPduRCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: C4310: cast truncates constant value</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler warns for cast truncates constant value

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
If the uint8_least is of type  unsigned char

The Platform_Types.h contains the following define

typedef unsigned char         uint8_least;   /* At least 8 bit                 */


Hint:
-------------------------------------------------------------------
The compiler warning is known and has been analyzed thoroughly for its impact on the code. Nevertheless it will not be fixed due to ensure that the init value is large enough. A cast to a smaller value is acceptable and has no impact on the application.  

#define PDUR_INVALID_VARARRAYIDX       ((uint16)0xFFFF)  is cast for unsigned char  to 0xFF which is correct.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
ignore the warning

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.00.00</firstAffectedVersion>
         <versionsFixed>11.00.00</versionsFixed>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00090161</identifier>
         <package>Ccl_Asr4ComMCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: condition evaluates always to true/false</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler warns for conditional expression being constant
a) in the function ComM_Init() when checking the generated data. Compiler warns about condition being always false in the following conditions:
if (ComM_GetWakeupStateOfChannel(ComM_ChannelIndex) &gt;= COMM_MAX_NUMBER_OF_STATES)
if (ComM_GetSizeOfChannel() != ComM_GetSizeOfChannelPb())
if (ComM_GetSizeOfPnc() != ComM_GetSizeOfPncPb())
As secondary effect compiler might warn about unreachable code/statement.

b) in the function ComM_PncProcessRxSignalEra() compiler warns about condition being always true in
if(ComM_IsSynchronizedOfPnc(pncIndex))

c) in the functions ComM_PncSetBitInSignal() and ComM_PncClearBitInSignal() when checking the generated data. Compiler warns about condition being always true in
if( signalByteIndex &lt; ComM_GetSizeOfPncSignalValues() )

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
a) occurs when COMM_DEV_ERROR_DETECT == STD_ON

b) occurs when
- 'Pnc Support' is enabled in ComM (/MICROSAR/ComM/ComMGeneral/ComMPncSupport)
AND
- 'Pnc Gateway Enabled' is enabled in ComM (/MICROSAR/ComM/ComMGeneral/ComMPncGatewayEnabled)
AND
- Only one PNC exists (COMM_ACTIVE_PNC == 1U, can be found in ComM_Cfg.h).

c) occurs when 'Pnc Support' is enabled in ComM (/MICROSAR/ComM/ComMGeneral/ComMPncSupport)

Hint:
-------------------------------------------------------------------
The compiler warning is known and has been analyzed thoroughly for its impact on the code. Nevertheless it will not be fixed because no simple remedy exist.
The warning is caused by an if-statement applied on external configuration data. Configuration data is const for the given compilation context but might be changed at post-build time.</problemDescription>
         <firstAffectedVersion>7.00.01</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00097289</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: integer literal is too large to be represented in a signed integer type, interpreting as unsigned</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler issues a warning: integer literal is too large to be represented in a signed integer type, interpreting as unsigned when
a lower limit define from the RTE is used.

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
This happens when the configuration contains application data type that are mapped to signed 64-bit integer types
and when the lower limit is configured to -9223372036854775808.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.05.00</firstAffectedVersion>
         <versionsFixed>1.17.00</versionsFixed>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00090831</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: integer conversion resulted in a change of sign</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler warns that "integer conversion resulted in a change of sign".

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
If the compiler WindRiver Diab is used. (found with version 5.9.4.2.)

Hint:
-------------------------------------------------------------------
The compiler warning is known and has been analyzed thoroughly for its impact on the code.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00098070</identifier>
         <package>MemService_AsrNvM</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: NvM_Cfg.c: 'ServiceId' : unreferenced formal parameter</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
1&gt;  NvM_Cfg.c
1&gt;..\..\Appl\GenDataVtt\NvM_Cfg.c(588): warning C4100: 'ServiceId' : unreferenced formal parameter

with Visual Studio compiler

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
Any configuration with disabled NvMMultiBlockCallback and NvMBswMMultiBlockJobStatusInformation</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>3.01.02</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00091295</identifier>
         <package>Ccl_Asr4ComMCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: dead assignment / variable set but not used</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler warns about an useless assignment to a local variable. Typically the warnings refer to local variables 'channel', 'errorId', 'Status' or 'User'.
Example compiler warning strings: 
"Useless assignment to variable 'abc'. Assigned value not used."
"Removed dead assignment"

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
EcuC Parameter 'Dummy Statement Kind' is set to 'SelfAssignment'. This can be detected in ComM_Cfg.c: #define COMM_DUMMY_STATEMENT(v) (v)=(v)

Hint:
-------------------------------------------------------------------
The compiler warning is known and has been analyzed thoroughly for its impact on the code. Nevertheless it will not be fixed because no simple remedy exist.
If Dummy Statement is switched off, other compiler warnings might occur e.g. "Unused/unreferenced variable".</problemDescription>
         <resolutionDescription/>
         <firstAffectedVersion>5.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00088061</identifier>
         <package>SysService_Asr4BswMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BswM_Lcfg.c: warning: 'function' : conversion from 'const BswM_ImmediateUserStartIdxOfModeReqeustMappingType' to 'BswM_SizeOfImmediateUserType', possible loss of data</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
BswM_Lcfg.c: warning: 'function' : conversion from 'const BswM_ImmediateUserStartIdxOfModeReqeustMappingType' to 'BswM_SizeOfImmediateUserType', possible loss of data

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
All</problemDescription>
         <firstAffectedVersion>7.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00074793</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: Condition is always constant</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler warning 'Condition is always constant'


When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   


In which configuration does this happen:
-------------------------------------------------------------------
Configurations without DTCs
AND
Precompile configuration</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
The warning can be ignored


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00097980</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: Unreferenced formal parameter due to reduction of rom data</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler warning occurs:  Unreferenced formal parameter 

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
/MICROSAR/Com/ComGeneration/ComReduceConstantData2Define is enabled
OR
/MICROSAR/Com/ComGeneral/ComOptimizeConstArrays2Define is enabled (in older releases).

Hint:
-------------------------------------------------------------------
The compiler warning is known and has been analyzed thoroughly for its impact on the code. Nevertheless it will not be fixed due to existence of a sufficient workaround.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Disable 

/MICROSAR/Com/ComGeneration/ComReduceConstantData2Define (in newer releases)
OR
/MICROSAR/Com/ComGeneral/ComOptimizeConstArrays2Define  (in older releases).


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00096807</identifier>
         <package>Ccl_Asr4ComMCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: possible loss of data due to implicit cast from uint16 to uint8</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler warns about possible loss of data due to conversion from uint16 to uint8 (implicit cast) for example
ComM.c(1287): warning C4244: '=' : conversion from 'const ComM_PncPbIndType' to 'ComM_PncIterType', possible loss of data

Code example and explanation:

typedef uint8_least ComM_PncIterType;
...
ComM_PncIterType pncIndex;
pncIndex = ComM_GetPncPbInd(pncPbIndIter); // the warning occurs because ComM_GetPncPbInd() returns a value of type uint16

There is no implication of this warning when using the code nevertheless. There is no loss of data because ComM_GetPncPbInd() returns a value that is always less than 64, which is the maximum number of partial network clusters (PNCs).


When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   


In which configuration does this happen:
-------------------------------------------------------------------
- Pnc Support is enabled (#define COMM_PNC_SUPPORT STD_ON can be found in ComM_Cfg.h)
and
- ComM module has configuration variant Postbuild Loadable (#define COMM_CONFIGURATION_VARIANT COMM_CONFIGURATION_VARIANT_POSTBUILD_LOADABLE can be found in ComM_Cfg.h)
and
- the type uint8_least is defined to uint8 (typedef unsigned char  uint8_least can be found in Platform_Types.h)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>8.01.01</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00079347</identifier>
         <package>FblWrapperFlash_Rh850Rv40His</package>
         <subpackage>Impl_Base</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>[BMW only] Compiler warning: incompatible redeclaration of variable "flashCode"</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The Greenhills compiler issues the following warning when compiling the fbl_flio.c:

"../../../CBD1400010/BSW/Flash/fbl_flio.c", line 95: warning #1544-D: 
           incompatibility associated with redeclaration of variable "flashCode"
           : data type differs from earlier declaration's unspecified type
   V_MEMRAM0 V_MEMRAM1 vuint8 V_MEMRAM2 flashCode[FLASH_SIZE];


When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
Warning occurs always.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
No workaround available.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.01.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00097692</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: conversion from 'int' to 'Dcm_CfgNetBufferSizeOptType'</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Compiler warns for possible loss of data: Check if cast is missing and if there is really a data loss due to an implicit/explicit cast on the target platform

When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   

In which configuration does this happen:
-------------------------------------------------------------------
- Service 0x22 is supported and handled by DCM (in Dcm_Cfg.h: #define DCM_SVC_22_SUPPORT_ENABLED == STD_ON)
AND
- DCM is configured to support DIDs with multiple signals (in Dcm_Cfg.h: #define DCM_DIDMGR_MULTISIGNAL_ENABLED == STD_ON)
AND
- At least one DID supports read operation (in Dcm_Cfg.h: #define DCM_DIDMGR_OPTYPE_READ_ENABLED == STD_ON)</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Ignore the warnings, since there is no danger of data value truncation.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>4.01.00</firstAffectedVersion>
         <versionsFixed>9.02.00</versionsFixed>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00089972</identifier>
         <package>Ccl_Asr4SmFr</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: 	Useless assignment to variable StdReturnValue. Assigned value not used.</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Useless assignment to variable StdReturnValue. Assigned value not used.
- Compiler warns for an unused assigned value. Can be accepted
StdReturnValue is set to E_NOT_OK as default value


When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code in case the configuration is as described below.   


In which configuration does this happen:
-------------------------------------------------------------------
If development error detection is disabled.
Detected with   WindRiver DiabData 5.9.4.7,   but other compiler might also be affected.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Cause of the Warning does not lead to side effects and can be set to the ignore list.

 
Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="compilerWarning">
         <identifier>ESCAN00097339</identifier>
         <package>Diag_Asr4Dem</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Warning in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>Compiler warning: possible truncation at implicit conversion</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
compiler issues a warning due to value truncation

ctc E560: ["..\..\..\external\BSW\Dem\Dem_DTC_Implementation.h" 1272/25] possible truncation at implicit conversion to type "unsigned char"
ctc E560: ["..\..\..\external\BSW\Dem\Dem_Event_Implementation.h" 1540/15] possible truncation at implicit conversion to type "unsigned char"


When does this happen:
-------------------------------------------------------------------
The warning is issued by the compiler during compilation of the code


In which configuration does this happen:
-------------------------------------------------------------------
compiler handles enumeration size as integer instead of as small as the values allow</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
If there exist compiler settings that limit the enum size, this can prevent the warning.
Otherwise the warning can be ignored.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>13.06.00</firstAffectedVersion>
         <versionsFixed>14.03.00</versionsFixed>
      </issue>
      <issue category="notReleased">
         <identifier>ESCAN00093797</identifier>
         <package>Os_CoreGen7</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BETA version - the BSW module has a feature with BETA state (Barriers)</headline>
         <problemDescription>What is the impact of BETA software:
-------------------------------------------------------------------
BETA software 
- must not be used in productive projects as they may result in unpredictable ECU behavior
- may not provide all features intended for the productive project
- is not or only partly tested and not all quality measures have taken place


Which functionality is BETA:
-------------------------------------------------------------------
The following feature/function is in BETA state. 
- Using barriers to synchronize tasks is implemented as a BETA feature. 

To ensure that only productive code is used verify that:
- No barriers (/MICROSAR/Os/OsBarrier) are configured in the configuration tool.</problemDescription>
         <resolutionDescription>API Extensions:
-------------------------------------------------------------------
No extension of the API.

API Changes:
-------------------------------------------------------------------
No modification of  the API.

Module handling changes:
-------------------------------------------------------------------
No modification of the module handling.

For a detailed description of the API and the handling of the module refer to the Technical Reference.</resolutionDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="notReleased">
         <identifier>ESCAN00088830</identifier>
         <package>Os_CoreGen7</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BETA version - the BSW module has a feature with BETA state (Memory Protection in trusted applications)</headline>
         <problemDescription>What is the impact of BETA software:
-------------------------------------------------------------------
BETA feature:
- must not be used in productive projects as they may result in unpredictable ECU behavior
- may not provide all features intended for the productive project
- is not tested and not all quality measures have taken place

 
Which functionality is BETA:
-------------------------------------------------------------------
The following feature/function is in BETA state. 
- Memory Protection in trusted applications.

To ensure that only productive code is used verify that:
- OsTrustedApplicationWithProtection is false for all applications.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Do not use memory protection for trusted.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="notReleased">
         <identifier>ESCAN00096772</identifier>
         <package>DrvCrypto_CryWrapper</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BETA version - Virtual key elements are only provided as a BETA feature.</headline>
         <problemDescription>What is the impact of BETA software:
-------------------------------------------------------------------
BETA software 
- must not be used in productive projects as they may result in unpredictable ECU behavior
- may not provide all features intended for the productive project
- is not or only partly tested and not all quality measures have taken place

Which functionality is BETA:
-------------------------------------------------------------------
The following feature/function is in BETA state. 
- Usage of virtual key elements 

To ensure that only productive code is used verify that:
- optional CryptoKeyElementVirtualTargetRef may not be used
- CRYPTO_30_CRYWRAPPER_KEYELEMENTINFOVIRTUALUSEDOFKEYELEMENTINFO is set STD_OFF

Exclusion: It can be used when the keys are located in hardware.</problemDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="notReleased">
         <identifier>ESCAN00093813</identifier>
         <package>Os_CoreGen7</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BETA version - the BSW module has a feature with BETA state (Fast Trusted Functions)</headline>
         <problemDescription>What is the impact of BETA software:
-------------------------------------------------------------------
BETA software 
- must not be used in productive projects as they may result in unpredictable ECU behavior
- may not provide all features intended for the productive project
- is not or only partly tested and not all quality measures have taken place

Which functionality is BETA:
-------------------------------------------------------------------
The following feature/function is in BETA state. 
- Os_CallFastTrustedFunction() API

To ensure that only productive code is used verify that:
- No elements are configured in /MICROSAR/Os/OsApplication/OsApplicationFastTrustedFunction</problemDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="notReleased">
         <identifier>ESCAN00083894</identifier>
         <package>Ccl_Asr4SmFr</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BETA version - the BSW module has a feature with BETA state (FEAT-1440)</headline>
         <problemDescription>What is the impact of BETA software:
-------------------------------------------------------------------
BETA software 
- must not be used in productive projects as they may result in unpredictable ECU behavior
- may not provide all features intended for the productive project
- is not or only partly tested and not all quality measures have taken place
 
Which functionality is BETA:
-------------------------------------------------------------------
The following feature/function is in BETA state. 
- ESCAN00083893Allow Wake Up Attempts On Both Channels

To ensure that only productive code is used verify that:
- Switch FRSM_WAKEUP_ON_BOTH_CHANNELS_ALLOWED is disabled in configuration tool</problemDescription>
         <firstAffectedVersion>2.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="notReleased">
         <identifier>ESCAN00089701</identifier>
         <package>Os_CoreGen7</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BETA version - the BSW module has a feature with BETA state (Executing trusted applications in non privileged mode)</headline>
         <problemDescription>What is the impact of BETA software:
-------------------------------------------------------------------
BETA feature:
- must not be used in productive projects as they may result in unpredictable ECU behavior
- may not provide all features intended for the productive project
- is not tested and not all quality measures have taken place

 
Which functionality is BETA:
-------------------------------------------------------------------
The following feature/function is in BETA state. 
- Executing trusted applications in non privileged mode is implemented as a BETA feature:

To ensure that only productive code is used verify that:
- IsPrivileged is TRUE for all trusted applications</problemDescription>
         <resolutionDescription>API Extensions:
-------------------------------------------------------------------
No extension of the API.

API Changes:
-------------------------------------------------------------------
No modification of  the API.

Module handling changes:
-------------------------------------------------------------------
No modification of the module handling.

For a detailed description of the API and the handling of the module refer to the Technical Reference.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="notReleased">
         <identifier>ESCAN00096853</identifier>
         <package>MSR_Bmw_SLP4</package>
         <subpackage>Preconfig</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BETA version - the Program (MSR_Bmw_SLP4) is in BETA state.</headline>
         <problemDescription>What is the impact of BETA software:
-------------------------------------------------------------------
BETA software 
- must not be used in productive projects as they may result in unpredictable ECU behavior
- may not provide all features intended for the productive project
- is not or only partly tested and not all quality measures have taken place
�
Which functionality is BETA:
-------------------------------------------------------------------
The complete BSW module is in BETA state

//ToDo
- set the state to ANALYZED
- assign the BETA ESCAN to the most affected sub-package
- add a separate BETA ESCAN to each sub-package only, if there is a risk of undetected delivery of BETA functionality (e.g. sub-package is used in different package branches)
- remove ToDo checklist</problemDescription>
         <firstAffectedVersion>19.06.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="notReleased">
         <identifier>ESCAN00092764</identifier>
         <package>Ccl_Asr4ComMCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BETA version - the BSW module has a feature with BETA state (FEAT-1454)</headline>
         <problemDescription>What is the impact of BETA software:
-------------------------------------------------------------------
BETA software 
- must not be used in productive projects as they may result in unpredictable ECU behavior
- may not provide all features intended for the productive project
- is not or only partly tested and not all quality measures have taken place
 
Which functionality is BETA:
-------------------------------------------------------------------
The following feature/function is in BETA state. 
- FEAT-1454: Configuration of Switch Ports (switchable per PNC)

The above feature/function has following limitations:
- CFG5 do not provide any validations rules. A proper feature configuration has to be ensured manually.
- Use case PB-L is not supported.
- PNCs having at least one /MICROSAR/ComM/ComMConfigSet/ComMPnc/ComMPortGroupsPerPnc require a ComM user.

To ensure that only productive code is used verify that:
- /MICROSAR/ComM/ComMConfigSet/ComMPnc/ComMPortGroupsPerPnc does not exist.
and
- ensure that COMM_WAKEUPENABLEDOFPNC is defined to STD_OFF in ComM_Cfg.h. 
   Note: otherwise MSSV fails with error message 'assertion 'COMM_WAKEUPENABLEDOFPNC: "STD_ON"' == '"STD_OFF"' does not hold'.</problemDescription>
         <firstAffectedVersion>8.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="notReleased">
         <identifier>ESCAN00092470</identifier>
         <package>SysService_Asr4BswMCfg5</package>
         <subpackage>GenTool_GeneratorMsr</subpackage>
         <severity>Low</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>false</safetyRelevant>
         <headline>BETA version - the BSW module has a feature with BETA state (FEAT-1454)</headline>
         <problemDescription>What is the impact of BETA software:
-------------------------------------------------------------------
BETA software 
- must not be used in productive projects as they may result in unpredictable ECU behavior
- may not provide all features intended for the productive project
- is not or only partly tested and not all quality measures have taken place


Which functionality is BETA:
-------------------------------------------------------------------
The following feature/function is in BETA state. 
- Configuration of Switch Ports (Mode Request Port (BswM_EthIf_PortGroupLinkStateChg))

Additonal:
Currently the BswM general switch BswMEthIfEnabled is not set via a Auto-Validation. During fixing of this BETA ESCAN a validation has to be implemented which ensures that the BswMEthIfEnabled is true if the EthIf calls this API and if the Mode Request Port is configured in BswM.</problemDescription>
         <firstAffectedVersion>10.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="safetyRelevant">
         <identifier>ESCAN00098052</identifier>
         <package>Os_PlatformRH850Gen7</package>
         <subpackage>Implementation</subpackage>
         <severity>Critical</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>true</safetyRelevant>
         <headline>Undefined behavior of OS after context switch (RH850)</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The OS shows undefined behavior after a context switch which may not be detected immediately.

When does this happen:
-------------------------------------------------------------------
This happens always and immediately at certain types of context switches. However, it is very unlikely that this problem occurs in a well tested system. Please see the description of technical background for more information.

In which configuration does this happen:
-------------------------------------------------------------------
The issue occurs independently from the configuration.

Technical Background:
-------------------------------------------------------------------
The cause of the undefined behavior is that a set of OS scratch register values is destroyed at a context switch. Dependent on compiler options and OS settings, some of these registers may be in use by the OS code after return from a context switch.  If so, OS data will be destroyed. The type of destroyed data depends on optimization decisions of the compiler.  Because of the structure of the OS code, it is quite unlikely that the OS code has any of these registers in use across a context switch. The context of the application is not affected.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
Do not allow compiler to inline functions

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.00.00</firstAffectedVersion>
         <versionsFixed>2.14.00</versionsFixed>
      </issue>
      <issue category="safetyRelevant">
         <identifier>ESCAN00097901</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>Critical</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>true</safetyRelevant>
         <headline>Rx Deferred Event Cache leads to unexpected ECU behaviour under high load</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The usage of deferred event cache leads to  unexpected ECU behaviour under high load.

When does this happen:
-------------------------------------------------------------------
Error may occur during run time, whenever it's temporarily required to open the interrupt locks. It is most likely to occur whenever Com_RxIndication is called in high frequency. 

In which configuration does this happen:
-------------------------------------------------------------------
ComDeferredEventCacheSupport == TRUE</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
(Increase ComRxDeferredEventCacheSize
AND
increase ComRxDeferredProcessingISRLockThreshold (if configurable)
AND
increase ComRxDeferredNotificationCacheSize  (if configurable))

OR

Deactivate ComDeferredEventCacheSupport

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>8.01.00</firstAffectedVersion>
         <versionsFixed>12.00.02, 13.03.03, 14.00.01</versionsFixed>
      </issue>
      <issue category="safetyRelevant">
         <identifier>ESCAN00097644</identifier>
         <package>Rte_Core</package>
         <subpackage>Implementation</subpackage>
         <severity>Critical</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>true</safetyRelevant>
         <headline>RTE dereferences NULL_PTR after execution of a mapped server runnable</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
RTE dereferences a null pointer after a mapped server runnable has been executed.
This usually results in an os trap.


When does this happen:
-------------------------------------------------------------------
During runtime when a client with lower task priority calls a mapped server runnable with higher priority.


In which configuration does this happen:
-------------------------------------------------------------------
This happens when multiple clients are connected to the same server, and the server runnable
is mapped to a task with higher priority than at least one of the clients. This happens only for
synchronous client server communication.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
- map the server runnable to a task with lower priority than the client tasks
or
- create a proxy component that forwards the client calls to the server.
To do so a server port + server runnable is created for each client.
Each client is connected to the corresponding proxy server port.
A single proxy client port is connected to the server.
The server runnables of the proxy component calls the server through the single client port.


Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>1.13.00</firstAffectedVersion>
         <versionsFixed>1.18.00</versionsFixed>
      </issue>
      <issue category="safetyRelevant">
         <identifier>ESCAN00097518</identifier>
         <package>MemService_AsrNvM</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>true</safetyRelevant>
         <headline>CRC32 calculations deliver wrong results</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
CRC32s calculated internally by NVM are not as specified by AUTOSAR, i.e. the results may differ, depending on number of single CRC library calls done per NVM block.
Calculated values are still CRCs, but they don't match the results from using corresponding standardized CRC32 calculations

Since CRC handling is done internally, this is usually not visible to users.

The issue becomes visible, if NVM's configuration changed between a write and a read request (see below): Data may become unreadable due to failed CRC check.


When does this happen:
-------------------------------------------------------------------
It happens at run-time during CRC calculation.
However this behavior is symmetric, i.e. calculated CRC during writes match the CRC calculated during reads. Data can be written and read back as expected.


In which configuration does this happen:
-------------------------------------------------------------------
It happens for all blocks having CRC (NvMBlockUseCrc) enabled, and CRC type (NvMBlockCrcType) was set to CRC32 .
If (in a running project), the number of "Bytes per MainFunction" (NvMCrcNumOfBytes) was changed, existing data become unreadable, because same data result in different CRC.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
In in a running project's configuration don't change the number of "Bytes per MainFunction" (NvMCrcNumOfBytes).

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>5.00.00</firstAffectedVersion>
         <versionsFixed/>
      </issue>
      <issue category="safetyRelevant">
         <identifier>ESCAN00097911</identifier>
         <package>Il_AsrComCfg5</package>
         <subpackage>Implementation</subpackage>
         <severity>High</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>true</safetyRelevant>
         <headline>Deferred PDUs are not processed using deferred event Cache</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Deferred Rx PDUs might not be processed if deferred event cache is enabled. This situation will sustain until the deferred event cache overflows. 

When does this happen:
-------------------------------------------------------------------
This issue may occur at runtime, whenever more deferred PDUs are received than the cache can store. In this case the fallback strategy will be applied. 
If during processing of the deferred PDU's new deferred PDUs are received, they might not be cached properly.


In which configuration does this happen:
-------------------------------------------------------------------
ComDeferredEventCacheSupport == TRUE
AND
type of processed Rx PDU is set to DEFERRED</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
If possible, set ComDeferredEventCacheSupport == FALSE. Otherwise no workaround is available.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>8.01.00</firstAffectedVersion>
         <versionsFixed>14.00.01, 13.03.03, 12.00.02</versionsFixed>
      </issue>
      <issue category="safetyRelevant">
         <identifier>ESCAN00097829</identifier>
         <package>Diag_Asr4Dcm</package>
         <subpackage>Implementation</subpackage>
         <severity>Critical</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>true</safetyRelevant>
         <headline>Service 0x22: Overwritten call stack</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
The call stack will be corrupted leading to indeterminable behavior.
The possible amount of overwritten memory depends on the largest configured DID.

After ECU reset, the normal operation should be possible.


When does this happen:
-------------------------------------------------------------------
- When any asynchronous DID is requested via service 0x22.
AND
- The access to the DID specific data elements is configured to be via a C/S interface (in DCM ECUC: /Dcm/DcmConfigSet/DcmDsp/DcmDspData/DcmDspDataUsePort == USE_DATA_ASYNCH_CLIENT_SERVER or USE_PAGED_DATA_ASYNCH_CLIENT_SERVER)
AND
- The maximal length of that DID is larger than one byte.
AND
-The read operation of that DID is cancelled due to
	- an interruption by a request of another tester with higher priority
	OR
	- Reaching the RCR-RP limit.


In which configuration does this happen:
-------------------------------------------------------------------
- Service 0x22 is supported and handled by DCM (in Dcm_Cfg.h: #define DCM_SVC_22_SUPPORT_ENABLED == STD_ON)
AND
- There is at least one DID with a data element (DcmDspData) configured to support paged read access (in Dcm_Cfg.h: #define DCM_DIDMGR_OPCLS_READ_PAGED_ENABLED == STD_ON)
AND
- The access to any data element is configured to be via a C/S interface (in DCM ECUC: /Dcm/DcmConfigSet/DcmDsp/DcmDspData/DcmDspDataUsePort == USE_DATA_ASYNCH_CLIENT_SERVER or USE_PAGED_DATA_ASYNCH_CLIENT_SERVER)
AND
	- DCM shall prioritize two or more diagnostic clients (e.g. OBD and UDS clients) (in Dcm_Cfg.h #define DCM_NET_PROTOCOL_PRIORITISATION_ENABLED == STD_ON)
	OR
	- RCR-RP transmission limitation is supported (in Dcm_Cfg.h #define DCM_DIAG_RCRRP_LIMIT_ENABLED == STD_ON)
AND
- There is an RTE used in the ECU project.
AND 
- The server runnable entity of those data elements has OsTask mapping other than the one the Dcm_MainFunction/-Worker() is mapped to.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
- Avoid OS-Task mapping of affected DID data element server runnable entities to let RTE optimize the C/S calls to simple C-function calls without data copies.
OR
- Do not use RTE C/S ports but simple callout functions (i.e. specify for DcmDspDataUsePort one of the applicable XXX_FNC values).
OR
- Omit usage of paged-DIDs, increasing the DCM buffer to fit all the paged-DID data at least in a single DID request of SID 0x22.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>7.02.00</firstAffectedVersion>
         <versionsFixed>9.03.00, 8.06.02</versionsFixed>
      </issue>
      <issue category="safetyRelevant">
         <identifier>ESCAN00097946</identifier>
         <package>Os_CoreGen7</package>
         <subpackage>Implementation</subpackage>
         <severity>Critical</severity>
         <issueClass>Issue in a released product</issueClass>
         <safetyRelevant>true</safetyRelevant>
         <headline>Interrupts are still disabled when returning from ResumeOSInterrupts or ReleaseSpinlock after the corresponding suspension API has been interrupted</headline>
         <problemDescription>What happens (symptoms):
-------------------------------------------------------------------
Interrupts are are not enabled when returning from ResumeOSInterrupts or ReleaseSpinlock.

When does this happen:
-------------------------------------------------------------------
This happens rarely, when SuspendOSInterrupts, GetSpinlock or TryToGetSpinlock is interrupted by an interrupt or preempted by another task at a certain short sequence of instructions. In any of the two cases interruption (1) and preemption (2) the described symptoms will only show up under additional circumstances:

(1) Interruption:
The interrupt uses use one of these APIs as well.

(2) Preemption:
The preempting task first calls GetResource() for a Resource that is assigned to at least one ISR and then one of the APIs mentioned.

In which configuration does this happen:
-------------------------------------------------------------------
This happens only if the configuration is as described below: 

(1) Interruption:
This happens only if Category 2 interrupts are configured (/MICROSAR/Os/OsIsr/OsIsrCategory == CATEGORY_2).

(2) Preemption:
The preempted task is configured to allow preemption (configured with /MICROSAR/Os/OsTask/OsTaskSchedule == FULL).
The preempting task is configured to use an ISR resource (/MICROSAR/Os/OsIsr/OsIsrResourceRef == given Resource). 

Above configuration restrictions are valid in case any of the described API functions is interrupted/preempted. In case of the spinlock API, an additional configuration restriction can be given:
In case one of the functions GetSpinlock or TryToGetSpinlock is interrupted/preempted, the symptoms only occur if the related Spinlock is configured with /MICROSAR/Os/OsSpinlock/OsSpinlockLockMethod == LOCK_CAT2_INTERRUPTS.</problemDescription>
         <resolutionDescription>Workaround:
-------------------------------------------------------------------
In order to avoid the issue the following APIs may  not be used within interrupts.
 - SuspendOSInterrupts (the ISR can be configured with EnableNesting = FALSE instead)
 - GetSpinlock (with a spinlock that uses /MICROSAR/Os/OsSpinlock/OsSpinlockLockMethod == LOCK_CAT2_INTERRUPTS)
 - TryToGetSpinlock (with a spinlock that uses /MICROSAR/Os/OsSpinlock/OsSpinlockLockMethod == LOCK_CAT2_INTERRUPTS)

Further, the APIs may not be nested within a GetResource()/ReleaseResource() pair where the respective resource is /MICROSAR/Os/OsIsr/OsIsrResourceRef of any OsIsr.

Additionally, if ESCAN00097942 is not present in the system, SuspendAllInterrupts can be used instead of SuspendOSInterrupts, and affected Spinlocks can be configured with /MICROSAR/Os/OsSpinlock/OsSpinlockLockMethod == LOCK_ALL_INTERRUPTS.

Resolution:
-------------------------------------------------------------------
The described issue is corrected by modification of all affected work-products.</resolutionDescription>
         <firstAffectedVersion>2.07.00</firstAffectedVersion>
         <versionsFixed>2.15.00</versionsFixed>
      </issue>
   </issues>
</issueReport>
